Changes between Version 3 and Version 4 of ExceptionRefactor

Show
Ignore:
Timestamp:
04/08/11 01:47:20 (3 years ago)
Author:
whiteknight
Comment:

add a quick note about why ExceptionHandler cannot be subclassed

Legend:

Unmodified
Added
Removed
Modified
  • ExceptionRefactor

    v3 v4  
    66 * ExceptionHandler PMC should be completely subclassable from PIR, and usable in all situations where an ExceptionHandler is used 
    77   * 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.set_pointer is used to set the target address AND the current runloop ID (for use with the finalize opcode). Object.set_pointer falls back to a delegate object, and sets the address/runloop_id on the delegate. In the finalize_p opcode, we do a GETATTR to fetch runloop_id from the Object, which isn't set. 
    89   * 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. 
    910 * The Embedding API needs an interface for C-based exception handlers. Prefer func pointers instead of jmp_buf, if possible. 
     
    1213   * BackTrace should also be completely subclassable. 
    1314 * 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.  
     15 
    1416 
    1517= Commentary And Issues =