Re^2: Modules return value

in reply to Re: Modules return value
in thread Modules return value

No, I can't think of any reason why you'd want to return a false value.

I can. Say you write a Parser to handle XML files. You might check during a BEGIN() if there is any functioning backend you can use. Yes, your module probably did some kind of test during install time, but that doesn't mean that those external libraries are still available and still functioning.

Now, why would you not want to just crash-and-burn or die()? Maybe your library is used from another module that's also dynamically searching for usable XML backends. There are many ways to load a ".pm" file (require, eval, probably Inline::Perl, ...), not just "use", and the easiest way to check if the operation worked is if you get a true value back. TIMTOWTDI, and yes that probably includes all the stuff that source code filters could do for (or "to") you ;-)

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP

Comment on Re^2: Modules return value

Replies are listed 'Best First'.
Re^3: Modules return value by kcott (Archbishop) on Jan 17, 2023 at 17:18 UTC
G'day cavac, While I don't necessarily disagree with anything you wrote there, I'm wondering if we're talking at cross-purposes. In the past, I've certainly written modules which, as part of loading, attempt to include some other module whose name is determined dynamically (perhaps based on environment, config, or similar). I would expect failure to be handled a little more elegantly: `Some/Module.pm failed to load because ...` [download] Rather than what you refer to as "crash-and-burn": `Some/Module.pm did not return a true value ...` [download] Could you provide some skeleton code that clarifies the scenario you're describing? Thankyou. — Ken	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Modules return value
by kcott (Archbishop) on Jan 17, 2023 at 17:18 UTC

G'day cavac,

While I don't necessarily disagree with anything you wrote there, I'm wondering if we're talking at cross-purposes.

In the past, I've certainly written modules which, as part of loading, attempt to include some other module whose name is determined dynamically (perhaps based on environment, config, or similar). I would expect failure to be handled a little more elegantly:

Some/Module.pm failed to load because ...
[download]

Rather than what you refer to as "crash-and-burn":

Some/Module.pm did not return a true value ...
[download]

Could you provide some skeleton code that clarifies the scenario you're describing? Thankyou.

— Ken

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom