Front page | perl.perl5.porters |
Postings from July 2013
Re: Try/Catch Exception Objects: Possible?
Thread Previous
|
Thread Next
From:
David E. Wheeler
Date:
July 25, 2013 11:13
Subject:
Re: Try/Catch Exception Objects: Possible?
Message ID:
39067C65-1814-4636-821B-56AA6FCF3197@justatheory.com
On Jul 24, 2013, at 5:31 AM, David Nicol <davidnicol@gmail.com> wrote:
> 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?
The latter is essentially the Perl 6 syntax, IIUC.
http://feather.perl6.nl/syn/S04.html#Exception_handlers
I personally prefer a keyword or something in front of my braces, but I could certainly use a label or `do`. The nice thing about try, though, is that it’s self-documenting. I do like having the catch inside the block, though.
> I don't know if a stack is really needed, a localizable $THROWN_PANIC
> might be enough.
I don’t understand. What is $THROWN_PANIC? If it is an exception object, why would it not need a trace?
I nearly always want a trace for my exception objects. The idea, for me, is such exceptions should be unexpected and reported to the developer, who will likely need the stack.
I have also often overloaded exceptions in my code for user-visible errors. This is convenient for preventing further execution and immediately showing the problem to the user (example: "The zip file you uploaded is corrupted"), but is expensive in that it creates and stores a stack that is never used (as, for example, Exception::Class does). Might be nice to have some other way of doing this, but I suspect that’s a separate discussion.
> Also, panic and defer-recover operate at the scope of function calls,
> not blocks. I am certain that Perl wants block granularity.
Yeah, though if we went with the nested catch, it would affect the lexical scope in which it is declared, block or function. Perhaps not file, though.
> 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.
Could be a chain, though. For example, Throwable has a previous_exception accessor, which tends to be pretty handy.
> 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?
Does Perl have a DEFER block? If not, should it be a part of this conversation?
I’m going to go back and think on this thread and come up with a proposal. I am going to make it as simple and iterative as I can.
Best,
David
Thread Previous
|
Thread Next