Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > 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 just want the cognitive simplicity of knowing that $@ and every
@@ isa Exception, no matter what.
Why not merge $!, $^E, and $@ into $!, but leave $@ alone too?
That way, none of the existing die/eval code will break without
being modified to check ref $!.
> > Now, hold on to your hat, %@ should the name of this
> > fault-hash...
>
> This is just an object in sheep's clothing.
Yes, but it's so simple that it maps directly into a fixed size
structure from the core's perspective, so it doesn't have to deal
with objects for errors, except when about to return failure at
a public API function, and that can be encapsulated. And, it's
extensible. But don't worry about %@, it's not important.
> > If C<use fatal;> is in scope, then just before returning, each
> > 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.
Agreed, modulo assert $@->isa("Exception"). I just meant:
$! and raise_exception_if_fatal_set($!);
where raise...set() would construct and throw a $@ based on $!, if
fatal is set. The %@ concept is, I agree, independent of this.
Yours, &c, Tony Olekshy
