Wouldn't it be more useful for the module to just die and report its own error message directly to the user (with the added benefit that he/she then has a line number with which to inquire into the module's source)? | [reply] |
Says Errto:
Wouldn't it be more useful for the module to just die and report its own error message directly to the user (with the added benefit that he/she then
has a line number with which to inquire into the module's source)?
Yes, it would. The reply above from Zaxo seems to miss the point---
a module that does not return a true value throws an exception anyway,
so nothing would be lost by saying that modules that want to
signal initialization failures should call die.
I think Larry agrees that the "true value" thing was a mistake.
(Compounding the mistake was Larry's decision to make failure,
rather than success, the
default.)
Way back when, I proposed that this mistake should be removed
in Perl 6; the revised proposal is here.
While I was researching the proposal, I looked at all the modules distributed
with the current version of Perl 5 to see if the "return false value to indicate failure"
feature was actually used. It turned out it was, but very infrequently.
99 of the 102 modules ended with an explicit 1;.
Two modules used the feature; the other called die explicitly
to indicate failure.
| [reply] |
Throwing an exception is a fine but different style of error handling. It requires that the caller wrap loading in eval to handle an error. In either case the module's docs need to specify how errors manifest to the caller, who is the only one who knows what to do with them.
Value error handling can get a message from $! if the module sets it and the interim code does not.
| [reply] |