The module or library can detect problems and prevent its own loading by returning false. A return call at top level in a file causes execution of the file to stop and return the corresponding value to the caller.

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)?

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.

--
Mark Dominus
Perl Paraphernalia

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.

After Compline,
Zaxo

My assumption was always that this allowed a module to try to load its own parts out of other files and then fail if it couldn't do so. For example, loading libraries, or loading autoloader-based .al files (e.g., if you're in a mod_perl environment and want to pre-load everything, a la CGI).

At the very least, even if these weren't the ideas at the time, it was flexible enough to allow things to happen. Quite contrary to YAGNI...

It indicates that initalisation completed successfully. If your module requires something to succeed for correct operation you can signal to whatever "requires" it a success value by returning success/fail as the last executable statement in the module.