At 01:42 AM 8/25/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> > If $@ and $! are merged, then in code like
> >
> > try {
> > system_call_that_fails();
> > more_stuff_that_succeeds();
> > }
> > finally {
> > }
> >
> > does the finally block think there is a current exception or not?
> > $! was set by the failed system call, but nothing died or threw.
> > If $@ is put into $! instead, how does the finally block know that
> > it's not an exception? ! ref($!) ...?
>
>I think it is imperative that if Perl has die and eval then it must
>have a flag that indicates *only* whether or not eval returned via
>normal local flow control or via non-local unwinding started by a
>die. Otherwise, I can see no way any quasi-reliable non-local flow
>control can be extened by writing blocks of local flow-control code.
>
>So if open, for example, can set $! without invoking die, then $!
>and $@ must not be merged. As I read it, 151 would (as currently
>promulgated) not meet my requirement for the unique nature of a
>$@-style variable. I don't think overloading ref to pick off true
>exceptions would make me happy either ;-)
Actually, think about it some more. Why not? If you want to implement RFC
88 as a module, then the ugliness, if there be any, of testing ref $!
instead of $@ is tucked away in one place only. The end user is not
bothered by any of this because if they inspect $! as a string, they'll get
the error message no matter what happened.
>I think that RFC 151 should be *merged* into RFC 80.
RFC 151 seeks to simplify the space of error variables for people doing
very short things without exceptions. I really don't want to muddle the
issue with structured exceptions; I just want to make sure it doesn't
obviate any of RFC 88.
> RFC 80
>should define a simple set of lower-case system-reserved fields
>to be used for signalling fault information by the Perl 6 core.
>RFC 80 should also define a mapping from this simple fault-hash
>into a proper Exception object (using, oh, say reference to a
>blessed copy of said fault-hash).
>
>Now, hold on to your hat, %@ should the name of this fault-hash...
> $@{type} "IO::File::NotFound"
> $@{message} "can't find file"
> $@{param} "/foo/bar/baz.dat"
> $@{child} $?
> $@{errno} $!
> $@{os_err} $^E
> $@{chunk} That chunk thingy in some msgs.
> $@{file} Source file name of caller.
> $@{line} Source line number of caller.
This is just an object in sheep's clothing. Worse, you've not only not
merged $!, $^E, and $@, which was the goal of RFC 151, you've made their
names longer. Breaking out all those attributes is fine, for them that
wants it; but then do it in an object. I'm trying to define an independent
proposal in RFC 151 for the folk who don't want to use exceptions and don't
want to scratch their heads to figure out what error variable to look at.
>%@ should not contain a severity or fatality classification.
>
>*Every* call to a core API function should clear %@.
>
>Internally, Perl can use a simple structured data type to hold the
>whole canonical %@. The code that handles reading from %@ will
>construct it out of the internal data on the fly.
>
>If C<use fatal;> is in scope, then just before returning, each core
>API function should do something like: %@ and internal_die %@;
AFAICT this isn't necessary. If a core function experiences an error, if
Fatal is in scope, it dies by throwing an exception in $! which stringifies
to the usual error text. If it isn't in scope, it sets $! to that error
text. Good backwards compatability karma.
>The internal_die becomes the one place where a canonical Exception
>can be generated to encapsulate %@ just before raising an exception,
>whether or not the use of such canonical Exceptions is controlled by
>a pragma such as C<use exceptions;>.
--
Peter Scott
Pacific Systems Design Technologies
