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