Changes between Version 2 and Version 3 of ExceptionRefactor
- Timestamp:
- 01/11/11 15:50:21 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ExceptionRefactor
v2 v3 1 > This page documents my (Austin) response to a [http://irclog.perlgeek.de/parrot/2010-02-22#i_2018722 request] from Tene to complain [http://irclog.perlgeek.de/parrot/2010-02-21#i_2018057 more] about exceptions. This is like a "super TT#" in that maybe a bunch of change orders come out of it. (Maybe 0, too.) So other folks please, ''please'' chime in with stuff you know, or opine, about how exceptions ought to work.2 1 3 > --Austin 4 ---- 2 = Tasks = 3 4 * Exception PMC should be completely subclassable from PIR. An Exception Subclass should be able to be passed to throw, die, rethrow, finalize, etc. 5 * Allow ExceptionHandlers to be able to filter the kinds of Exception it catches by class/role/VTABLE_does/VTABLE_isa/etc 6 * ExceptionHandler PMC should be completely subclassable from PIR, and usable in all situations where an ExceptionHandler is used 7 * ExceptionHandler should be allowed to be, or be subclassed with, A Sub-like type. So long as the ExceptionHandler subclass implements VTABLE_invoke and a few other attributes, it should be usable as expected. 8 * ExceptionHandler PMC should have an option that forces it to be popped off the handlers list automatically when it is invoked. These kinds of handlers can be used to avoid infinite recursion of handlers throwing exceptions. 9 * The Embedding API needs an interface for C-based exception handlers. Prefer func pointers instead of jmp_buf, if possible. 10 * Backtraces should show information about an Exception from the period before a rethrow (TT #1283) 11 * Create a new BackTrace PMC type that encapsulates a backtrace and provides programmatic access to the contents in a backtrace, and also a preformatted string representation of it. 12 * BackTrace should also be completely subclassable. 13 * Simplify attr processing in Exception. The current algorithm to look up attr_ enum values in a long string of if(STRING_equal(...)) is very bad for performance. 14 15 = Commentary And Issues = 5 16 6 17 The point of exceptions is to enable a whole bunch of 'dynamic' (like scope) flow control. 7 18 8 = 'Typed' exceptions=19 == 'Typed' exceptions == 9 20 10 21 The PCT stuff uses exceptions for things like return, break, and continue, as well as the conventional "a surprising result has occurred." … … 14 25 It is conceivable that more types could be added. 15 26 16 = 'Classed' exceptions=27 == 'Classed' exceptions == 17 28 18 29 Most programming languages support the idea of exception classes. Further, they support catching exceptions based on a class hierarchy: catch an exception of such-and-such class, or any subclass. … … 22 33 So catching a classed exception either looks like "catch all exceptions, then filter by class, then rethrow the ones you don't like", or it looks like "register the classes you catch, some of which may be subclasses of each other, and have the dispatcher run through the 'isa' query to find a match". 23 34 24 = 'Resumable' exceptions=35 == 'Resumable' exceptions == 25 36 26 37 Perl is driving the idea of resumable exceptions, I think. (I remember advocating for it on p6l about 80 years ago.) This causes a problem in that a resumable exception doesn't ''necessarily'' roll up the stack. A non-resumable exception, which is what the industry is used to, does. … … 28 39 So a resumable exception is kind of like the old `ON ERR GOSUB` directive - it calls a "sub-routine" (maybe) that might possibly return back to the site of the exception (or to some other continuation, blah blah). Or it might never be heard from again. 29 40 30 = 'finally'=41 == 'finally' == 31 42 32 43 There's no obvious way to implement `finally`, or something like it, if an outer exception handler is going to ''maybe'' resume the exception. If the exception is non-resumable, you can close those files. If the exception is definitely going to be resumed you should ''not'' close the files. But if you don't know, then what? … … 34 45 (The only answer to this that springs immediately to mind is to have a "last" exception handler that converts a resumable to a non-resumable, and throws ''that.'' I sure hope somebody smarter than me has thought about this...) 35 46 36 = Requirements=47 == Requirements == 37 48 38 49 The current typed system fails to handle this approach. It is unlikely that a single-type-per-exception approach will ever perform adequately in the presence of multiple inheritance and role mixins. … … 53 64 * Catchable exceptions should be handled well, but may trade performance for implementation facility. 54 65 55 = Design Issues=66 == Design Issues == 56 67 57 68 A cloud over much of this is coroutines. Coroutines, or some other form of random flow, have to support separate "stacks" for control transfer. That is, if a lexical block throws a "loop break" control exception, the right outer block has to receive it. I suspect this may have already been thought through - I certainly hope so.
