Does the failure in the read() call happen in the same calling program that used the save() call? (I trust you are making sure to save something to the file before trying to read it...)
Sorry, no answers yet, just questions. That's because I don't see anything wrong with the code as it stands. Maybe I would add parens around the args in the tie call, and use "or die" instead of "|| die", just to make sure there isn't any confusion about precedence (e.g. just in case the GDBM_READER constant is defined as "0", which means that the last arg to tie would be parsed as "GDBM_READER || die", which would evaluate to the return value of the "die" call -- not what you want).
Update: having seen the first reply (posted while I was writing this one), it's plausible that adding the extra permission arg (which would always evaluate to true) before the "|| die" works because it's another way of decoupling "GDBM_READER" and "|| die". If this is the case, that "die" call might never get invoked as a result of a failed return from tie. I'd still suggest using parens and "or die".
Another update: sure, you can just add parens around the tie args, or just switch from "|| die" to "or die" -- either step by itself would be sufficient. But you need to do at least one of them if you want that "die" trap to really work as intended.
In reply to Re: GDBM_File dies without telling why
by graff
in thread GDBM_File dies without telling why
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |