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

Re: Try/Catch Exception Objects: Possible?

Thread Previous | Thread Next
From:
David Golden
Date:
July 23, 2013 18:33
Subject:
Re: Try/Catch Exception Objects: Possible?
Message ID:
CAOeq1c_SHM7HjELe=rbsnLDepbpjriGFyJqiF6qTbyTefwiu6g@mail.gmail.com
On Mon, Jul 22, 2013 at 5:44 PM, David E. Wheeler <david@justatheory.com> wrote:
> I would be interested in learning what thoughts others have had.

The last time I thought this through in any detail, this is what I came up with.

https://gist.github.com/dagolden/6064767

I got some helpful feedback, but never found the tuits and inspiration
to attempt to do anything about it.  Maybe someone else will find it
useful.

> My guess is that the hard part would be in ensuring backward-compatibility. Not all existing exception-handling code can handle even an object that stringfies to its original. Even if it did, there are *so* many modules out there now that throw references instead of strings, and they may not work at all.

If you read my gist, you saw that my suggestion was to use the
inside-out pattern to wrap objects/references.  That would allow
things that check for an error with "isa" rather than class equality
to still work.

More to the point, if the new "make all exceptions an object" only
happens with the 'try' feature, then old code should continue to work
as it does.

> If so, how about this: Have `die` create an object, but only set it up for use when the new CATCH OP is executed. Or perhaps even leave the value passed to `die` in the $@ global, but set lexical $_ to the new core object. So in all the places exceptions were previously used, they should be the same as ever, and only upgraded to core exception objects in CATCH blocks.

I would recommend using $@ for familiarity.

The big question to me is this: should dying throw objects or should
catching upgrade things into objects?  (And how much of this can be
controlled lexically?) Dying with objects seems cleaner, otherwise
catch code is going to be parsing for strings thrown by the core,
which seems hackish and fragile.

It might make sense to split this up into relatively orthogonal chunks:

(1) can we change from core throwing string exceptions to throwing
objects?  (if so, should it be flat or hierarchical)

(2) can we change die to munge strings/references/objects into a
consistent framework?

(3) can we define semantics for a core try/catch/finally/etc construct

I think the answer to each informs the next.  If #1 and #2 are sorted
out, then it impacts what we might want of #3.

> Crazy? Impossible? Terrifying?

Yes, no, yes.

David

-- 
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About