Front page | perl.perl5.porters |
Postings from July 2013
The examples of try syntax all make me wonder why the try is needed. Is there an
advantage to
> try {
> risky();
> }
> catch my $err {
> ...
> }
over
> {
> risky();
> catch my $err {
> ...
> }
> }
and if so what is it?
I don't know if a stack is really needed, a localizable $THROWN_PANIC
might be enough. Supporting multiple active exceptions at the same
time might work as a new way to fork an intercal program though, along
with multiple COME FROM statements referring to the same label :)
Golang's panic and recover are documented here:
http://golang.org/pkg/builtin/#panic
The golang documentation does not speak to what happens when one
panics during a panic that has not been recovered from yet. I presume
that either (1) recover returns the most recent panic, and stops all
panicking or (2) panicking during a panic is a no-op, so recover
returns the first panic.
It also does not explicitly suggest
defer func () {
if r := recover(); r != nil {
if expected_exception(r) {
...
} else {
panic r
}
}
}
as a way to handle specific exceptions only, but that is implied
pretty strongly.
Also, panic and defer-recover operate at the scope of function calls,
not blocks. I am certain that Perl wants block granularity.
On Tue, Jul 23, 2013 at 9:41 PM, David Nicol <davidnicol@gmail.com> wrote:
> I see how one could create a pure-perl YodaCatch, using the hack from
> Scope::local_OnExit, but the syntax would wind up looking like
>
> local @YodaCatch = ( FooE => sub { ... }, );
on second thought, that wouldn't work in pure perl; Some XS would be
needed to stop the upward propagation of the thrown exception and
insert the result of the triggered catch block as the value returned
from the block containing that catch block.
My internal jury is still out on the question of, does it make more
sense to deal with the last exception thrown, the first exception
thrown, or to have a queue of them that must all be handled to resume
normal operations. I don't think it's possible to have simultaneous
exceptions in C++, outside of an easy-to-imagine system that might
embed a list of complaints in a complicated exception object.
Given a DEFER block that executes even during a panic, however,
situations with multiple cascading exceptions are easy to imagine: the
external storage gets unplugged and suddenly all the deferred file
closes and mutex unlocks fail, throwing exceptions that are only
caught at the top-level dispatch. Which exceptions get caught, and in
what order?
Thread Previous
|
Thread Next