develooper Front page | perl.perl5.porters | Postings from July 2013

Re: Try/Catch Exception Objects: Possible?

Thread Previous | Thread Next
David E. Wheeler
July 25, 2013 13:28
Re: Try/Catch Exception Objects: Possible?
Message ID:
On Jul 25, 2013, at 3:16 PM, David Nicol <> wrote:

> by "stack" here I meant more than one active exception at the same
> time, possibly living in @@. I did not intend to allude to traces.
> $THROWN_PANIC is a placeholder for the new single thing that is not $@.


>> 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.
> why not file?

I don’t know. Off the cuff it did not seem like a great idea. But now I can think of how it might be useful for one-off scripts. I might use a CATCH block instead of END to do final cleanup of open file handles or something in the even of an error. Or just nicely formatting any error.

So ignore my “Perhaps not file, though’ comment. :-)

>> Could be a chain, though. For example, Throwable has a previous_exception accessor, which tends to be pretty handy.
> or a "consume exception" operator that keeps producing them until it
> runs out and must be called in a loop. There would also have to be a
> way to inspect the current one. So just declaring some conventions
> around use of @@ gives everything we could possible need.

Yeah. I kind of think an object would be more useful, but it’s not that important to me one way or the other.

> Please tell more about Throwable's previous_exception accessor. I'm
> guessing it stashes the active exception when throwing while handling.


> Is there sugar for getting the first-thrown?


>> Does Perl have a DEFER block? If not, should it be a part of this conversation?
> Perl does not have a formal DEFER block. CPAN has Scope::OnExit and a
> pure-perl version providing similar semantics but clunky syntax, using
> the reassignment of previous values to localized variables as the
> trigger for running a coderef. DEFER is an essential part of golang's
> exception handling, and therefore belongs in this conversation.

Seems similar to Try::Tiny finally blocks, though not specifically associated with exception-handling. I can see how it would be useful, for sure, but not only in an exception-handling context, and likely without regard to any particular exception-handling functionality we come up with here.

So yeah, gimme some of that, but I don’t think it’s a requirement for in-core exception handling.



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About