Front page | perl.perl5.porters |
Postings from July 2013
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: @xdgThread Previous | Thread Next