On Saturday, August 31, 2002, at 05:06 PM, _brian_d_foy wrote:
> In article <454FBCFE-
> [EMAIL PROTECTED]>, Ken Williams
> <[EMAIL PROTECTED]> wrote:
>
>> The difference is primarily in the cases when a programmer
>> *forgets* to handle an error.
>
> the low level code can't know that, though.
My point exactly.
>> 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... }
Of course you can:
if (eval {open ...}) { ... }
else { ...recover... }
I think you can have whatever opinion you want about
liking/disliking exceptions, but they don't make different
things possible/impossible, they only make different things
easy/hard or brief/verbose. The set of things you can do is the
same.
About 99% of my code using open() does "open(...) or die ...;".
The other 1% does something like what you wrote above. I say
that's a poor ratio of making the *common* things easy.
In any case, I don't want to force your code to do anything in
particular, which is why I wrote that bit about wanting it to be
lexically configurable.
> 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.
>
Why not? What's the practical difference?
In any case, it's NOT an application level decision in the
low-level code. The caller still makes that decision. It's
just a different way for code to report "I wasn't able to do
what you asked me to do."
-Ken
