I have moved this to [EMAIL PROTECTED]
Jonathan Scott Duff wrote:
>
> Okay, imagine something for me:
>
> # some code here that may cause an exception
> exceptions { # when thrown, we end up here
> switch ($@->^_) {
> case canFoo { ... } # caught if canFoo
> case isa('IOError') { ... }
> case isa('MathError') { ... }
> throw $@; # rethrow unhandled
> }
> }
>
> This "exceptions" block is only entered if an exception is thrown
> in the current lexical scope. Inside the exceptions block we have
> access to the exception via $@ and access to the "unwinding
> information" via some other special variable that I haven't given
> a name yet as I'm not exactly sure what you mean :-) New keywords
> added: "throw" and "exceptions". Semantics supported: ignore
> unhandled or not (those that wish to ignore unhandled exceptions
> just omit the C<throw> at the end of the switch.)
>
> Now, in the interest of continuing my education, what did I leave
> out?
Problem 1:
In a large lexical scope, you have no preindication that intended
non-local flow control is in effect until you read all the way to
the end of the scope. The equivalent of your example in more human-
friendly terms is try { } exceptions { }.
Problem 2:
If you accidentally forget the "else throw" or whatever, you drop
the exception on the floor. Exceptions should propagate unless you
explicitly and completely handle them.
The same problem can happen with using return codes to signal failure.
If you forget to check the return code, the failure is dropped on the
floor.
Using exceptions for failure signalling is a more robust software
engineering technique, but only if your exception handling mechanism
doesn't "encourage" you to drop exceptions of the floor.
Yours, &c, Tony Olekshy
