Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
: 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. I think I agree with the folks that say errors should be caught by type, not by number. Just as a for instance, you ought to able to write a simple handler that catches any ERRNO-style error. Yup. Enumerating errors/warnings is awkward because it says you know beforehand all your possible errors/warnings. It is very static and non-extensible--having to recompile your Perl if you add/delete/change errors/warnings isn't exactly dynamic. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
Bart Lateur writes: : 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 $!). Whatever you do with the string or numeric part, I think the new $! should push the old $! onto its stack of the old exception objects. : 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. I think I agree with the folks that say errors should be caught by type, not by number. Just as a for instance, you ought to able to write a simple handler that catches any ERRNO-style error. Larry
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
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.
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote:
Merge C$!, C$^E, and C$@
Merging $! and $^E makes perfect sense to me. I don't know why there are
two different error variables. Er... wasn't that three? I'm not
absolutely certain, but I thought there was a third one, too. time
passes... Oh yes: $? AKA $CHILD_ERROR. Throw that in as well.
But $@ is an entirley different beast.
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $@;
$@ contains the whole user provided string, possibly including script
file name, line number and input record number. But $! is just the "file
does not exist" string. Two different things.
--
Bart.
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
At 10:37 PM 8/24/00 +0200, Bart Lateur wrote:
On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote:
Merge C$!, C$^E, and C$@
Merging $! and $^E makes perfect sense to me. I don't know why there are
two different error variables.
$! eq "No such file or directory"; $^E eq "CD-ROM drive door open" :-)
Er... wasn't that three? I'm not
absolutely certain, but I thought there was a third one, too. time
passes... Oh yes: $? AKA $CHILD_ERROR. Throw that in as well.
Actually I intentionally left it out. But I am starting to think you're right.
But $@ is an entirley different beast.
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $@;
$@ contains the whole user provided string, possibly including script
file name, line number and input record number. But $! is just the "file
does not exist" string. Two different things.
The proposal is that $! would be overwritten with the die string. Reason:
whoever's interested in both $@ and $! at the end of an eval? There was an
error; everyone looks at $@, which almost certainly contains $! if it was
useful. So the above becomes:
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $!; # Contains the user provided string etc
Yes, this is losing information; the former $! is no longer around. I
contend that it's eliding functionality that is seldom, if ever, used, in
favor of a natural simplification. There's one place where an error
message shows up. One. No need to figure out what kind of thing failed.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote:
But $@ is an entirley different beast.
The proposal is that $! would be overwritten with the die string. Reason:
whoever's interested in both $@ and $! at the end of an eval? There was an
error; everyone looks at $@, which almost certainly contains $! if it was
useful. So the above becomes:
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $!; # Contains the user provided string etc
Yes, this is losing information; the former $! is no longer around. I
contend that it's eliding functionality that is seldom, if ever, used, in
favor of a natural simplification. There's one place where an error
message shows up. One. No need to figure out what kind of thing failed.
There's a whole in your logic.
eval {
open "some_name_for_a_file_that_does_not_exist";
undef;
}
The eval will not fail ($@ not set), but $! will be set to something
like "file not found".
eval {
open "some_name_for_a_file_that_does_not_exist"
or die "Hoorible death: $!";
}
Now, as it is now, $@ *will be set, to the complete error message. $!
will be set, too.
$@ is *the* marker that something died inside the eval. You can't test
eval's return value: both examples return undef. $! is unreliable --
unless you're proposing that $! would be cleared at the end of the eval
block, if it doesn't fail (as is pretty much the case with $@ now).
--
Bart.
