be cleared if the eval doesn't fail, just like $@ is
now.
Yes. Basically, you can think of the new $! as getting done to it whatever
was last done to any of the set of $@, $!, $^E, and $? in the current Perl.
Well, I doubt it will be that simple :-)
--
Peter Scott
Pacific Systems Design Technologies
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
authors who wished to
to automatically support this functionality as well.
Got anything in mind? $^something?
--
Peter Scott
Pacific Systems Design Technologies
probably has way
too much time on their hands :-)
--
Peter Scott
Pacific Systems Design Technologies
" die.
There are no existing fatal exceptions. You can call die as much as you
want, but if your caller has wrapped you in an eval block, tough. RFC 88
does not change this at all.
--
Peter Scott
Pacific Systems Design Technologies
. That's how Error.pm implemented it and it
makes perfect sense. Nothing in RFC 88 precludes die and throw from
sharing the same underlying code, or simlarly catch/eval. I think it
should make it clear that they *are* the same thing.
--
Peter Scott
Pacific Systems Design Technologies
At 02:00 PM 8/22/00 -0600, Tony Olekshy wrote:
Peter Scott wrote:
I actually see nothing wrong in division returning undef for a
dividend of 0. It's just as easy to check as doing an eval.
Please don't do this. I would have to check every divide in all
my code, since no fatal
that was:
Any exception raised in a try will be fatal unless caught?
It already is (RFC 88).
--
Peter Scott
Pacific Systems Design Technologies
ds alright; there's something very self-defeating about raising a
run-time exception from dying badly, if you see what I mean.
So the third case goes and the second one becomes, args are stringified and
joined on '', etc.
--
Peter Scott
Pacific Systems Design Technologies
the exception stack in @_. If we use the RFC
63/Error.pm idea of passing the current exception in $_[0], then this falls
out naturally, and no need to follow a linked list. Gets my vote.
--
Peter Scott
Pacific Systems Design Technologies
the next enclosing try block). This will happen if an exception was not
caught, or if a catch or finally block threw an exception.
I note that under these rules it would be possible to have "try { ... }
finally { }" with no catch blocks. I guess that's okay.
--
Peter Scott
Pacific Systems Design Technologies
miles away.
chaim
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
One issue that haven't seen addressed, is how to _not_ have exceptions.
I want to use a core module (non-core can do anything they want) but
I'd like to write i
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS 1. When an exception is thrown perl looks for the enclosing try block; if
PS there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing
13 matches
Mail list logo
