in reply to Re: How do I use a block as an ‘or’ clause instead of a simple die?
in thread How do I use a block as an ‘or’ clause instead of a simple die?

Problem #1: You have an "or" statement, not a subroutine block therefore a return(-1) is nonsense...return -1 to where and to whom?

No, there's no reason to believe there's a problem with return. The snippet comes from a sub, that's all.

What I find odd is returning a true value on error. But it's not unheard of in specific circumstances (e.g. getc, index).

Replies are listed 'Best First'.
Re^3: How do I use a block as an ‘or’ clause instead of a simple die?
by Marshall (Canon) on Apr 18, 2009 at 20:18 UTC
    I had to hit CTL-+ a couple of times to get fonts large enough that I could see the details. I see your point, but even so, this -1 return value is very strange...there can be complications with signed vs unsigned, etc.

    Returning a non-zero value for an error is actually the "normal" way to do things. If I can only transmit one single number to you and that number has to combine the error code and the success status into that single number, then "success" has to mean Zero. Zero means I am completely happy. Something non-Zero is an error code. What's weird here is the -1.

    This all has to do with ancient stuff. A lot of these machines only had two registers, A and B, each 16 bits. In ASM, by convention simple status would get passed back to caller via A register. PDP-11, SEL-810, NOVA-800,etc. Now if all the bits were "on" FFFF, then is that -1 or 65535?

    Even the most wimpy machines will have a JNZ (jump non zero) or JZ (jump zero) instruction - it can be called something else, but there will be something like that. To detect -1 would have taken 2 instructions: one's complement(XOR), then JNZ or JZ. On a modern processor, the math unit is FAR larger than the CPU. All this happens at mind boggling rates.

    Anyway, yes there is a false dichotomy concerning "true/false" values. All I can say is that it is what it is.

      In Perl, false values are customarily used for errors (and not just for builtins).
        The part that was strange was the negative return value. Anyway, I showed how to keep track of the re-tries, etc which was the main point.

        In general, Perl does like C. There is some historical weirdness that we just have to live with. In Perl a .pm module has to return non-zero when "all is ok" (usually just by last line of 1;), but a Perl program returns (0) to the O/S if it works (*nix or Windoze). Perl should return a positive error code if it abends. This is strange and inconsistent and I'm not saying that it isn't.

        For the most part the Perl functions and C functions do what you expect in terms of true/false. In C there is weirdness with EOF, that's -1. So, yes there are funcs that return negative values for "true". In Perl most of these weirdo cases have been solved and I'm not saying that they aren't. I've never tested a loop for an EOF value in Perl... the subject just doesn't come up.

        I am saying that returning a negative number for an error code is a strange thing to do. If non-zero means a error code, then a positive number is far better than a negative number. For a T/F value, return either 0 or a positive number.