Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

vsergu (505)

vsergu
  (email not shown publicly)

Journal of vsergu (505)

Sunday November 02, 2003
10:13 AM

Insane return values

[ #15517 ]

From the documentation for the signon() method in Net::AOLIM (emphasis added):

Returns undef on failure, setting $main::IM_ERR and $main::IM_ERR_ARGS as appropriate. Returns 0 on success.

Aagh! And most of the other methods in the module seem to work the same way. Is there some strange programming subculture where such things make sense (perhaps there's a taboo against ever returning true values)?

Of course, I can't get the module to work anyway, so I may go back to Net::AIM, which was sort of working.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Just be glad they're mostly consistent. Sometimes you find functions that return "Y" / "N", or 1 / 0, or some 1 / undef, or some crazy combination, all in the same module...
  • Hrmmm (Score:2, Insightful)

    This isn't too bad - All you need to do is call defined on the return value and you have a clean test for whether a module call has succeeded. It could be much worse ... They might not have documented this behaviour or indeed any module return values at all.

    All of this is moot if the module doesn't work though

    :-)

    • Re:Hrmmm (Score:3, Informative)

      Isn't too bad? - I guess so. But they are stomping in the main:: namespace (rather than the caller's). Using fixed variables means that they are not threadsafe (at least in a 5.005 threads world, or anything non-perl that has POSIX-like threads semantics). Either point alone would be enough for me to toss this code back.

      • But they are stomping in the main:: namespace (rather than the caller's). Using fixed variables means that they are not threadsafe (at least in a 5.005 threads world, or anything non-perl that has POSIX-like threads semantics).

        Wholly agreed. The practice of manipulating variables within the main:: namespace would be something which I too would question. Not necessarily from the perspective of thread safety but for more pragmatic reasons relating to professional (developer) courtesy - Playing in other peo

    • Right, if it's documented, and is consistent across the module, what's the problem? If you prefer true/false, write a wrapper.

      And consider what happens if your function can legitimately return values from 0 upwards, or can fail. For instance "I updated 0 files in the specified directory" vs "I couldn't open the specified directory". In that case, I like to return undef for failure.