All the Perl that's Practical to Extract and Report

Insane return values

vsergu on 2003-11-02T15:13:17

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.

Y/N

rafael on 2003-11-02T17:14:37

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

rob_au on 2003-11-02T19:32:31

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

nicholas on 2003-11-02T23:47:55

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.

Re:Hrmmm

rob_au on 2003-11-03T01:06:48

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 people's gardens without permission (by way of variables exported at the request of the calling code) is simply not nice.

Re:Hrmmm

drhyde on 2003-11-03T13:34:25

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.