At 12:27 AM +0000 2/25/07, Ian Piper wrote: >Regarding EndException and ThreadEndException, do you think it would >be OK then to put if clauses to exclude those two exception types?
It would be best to only catch those exceptions you're prepared to handle. You could consider catching all exceptions and reraising the EndExceptions and ThreadEndExceptions. However that leaves you exposed to accidentally catching other private exceptions that RB might add in the future; or that might even exist now that we're not aware of. In the past I proposed having a way to distinguish between three exception priorities, either via a subclass/ISA mechanism or by a new runtime exception property. I think we need to have different categories of exceptions, which we can distinguish and even disable separately. * User Code Exceptions (Nil, OutOfBounds, etc) * Framework Warning Exceptions (Missing Encoding Tag, Numeric Overflow, etc) * RB Internal Exceptions (EndException, ThreadEndException, etc) My desire is to know which exceptions indicate a failure in my code, and a way to ignore RB's internal exceptions. I might want a way to always ignore RB Internal Exceptions, enable FrameworkExceptions only in debug builds but enable UserCodeExceptions in all builds. Sign on here if you agree. http://www.realsoftware.com/feedback/viewreport.php?reportid=ydoqdcdj Regards, Joe Huber _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
