In article <[EMAIL PROTECTED]>, Ken Williams
<[EMAIL PROTECTED]> wrote:
> This isn't a difference between return-error and throw-exception
> programming. The caller gets to make the decisions in either
> situation.
Perl doesn't have exceptions, so we don't get that choice.
> The difference is primarily in the cases when a programmer
> *forgets* to handle an error.
the low level code can't know that, though.
> Uncaught exceptions force you to
> take notice, whereas uncaught error values don't do much of
> anything. They just let some other problem happen later.
a possible exception also forces you to program in a certain way.
that's fine with languages that have that built-in, but that's not
Perl.
> Zillions of times, I've wished I could change open() into a
> function that dies upon failure, so I could just write
why do people have this die() fetish? if open dies, i can't
do something which is much better:
if( open ... ) { ... }
else { ...recover... }
in Perl, easy things should be easy. when you start letting
low level code make application level decisions, easy things
aren't easy anymore. throwing an exception is not the same
thing as dying.
