On Thu, 24 Aug 2000 17:12:11 -0700, Peter Scott wrote:
> eval {
> open "some_name_for_a_file_that_does_not_exist";
> # $! set to "file or directory does not exist"
> undef;
> }
> # $! set to "" (or undef, whichever makes more sense) on
> # eval block termination since no exception was thrown
>
>This makes sense because the programmer intentionally cleared the error
>indication by using a non-exception-throwing system call (open).
It does. I'm beginning to like it.
>Now, does the programmer need to know something died inside the eval? If
>so, they can use the RFC 88 mechanism (which will have to be based on
>something a bit more fundamental than just checking $! at block exits). If
>not - and many won't care - then they've got what they want - the error
>message.
Apropos those extended mechanisms: couldn't we use the same mechanism as
is currently in use for $!, for $@ too? I mean: $! in numerical context
gives an error number, in string context a text string. Then
die "I'm outta here: $!";
should assign both the numeric representation of $! and the new text
representation, the custom text, to the current $@ (future $!).
That numerical part could then form the basis of the extended exception
mechanism. No, the programmer shouldn't memorize the error numbers:
there should be predefined constants, like
ERROR::filenotfound
which are numeric, and which could then be used for the catch switch.
Well, maybe drop the "ERROR::" part for brevity -- but not for clarity.
--
Bart.
