All Good points. Related to this, I raised an FR a while back to provide a debugger option only to break on exceptions NOT being explicitly caught by a current try/catch clause. When one uses ones own exceptions and has written code to handle and deal with then , one might not want the debugger to break on those, while still being able to break on the UNEXPECTED ones - ie the unforeseen bugs.
On 25/2/07 01:12, "Joe Huber" <[EMAIL PROTECTED]> wrote: > 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. Regards, Dan _______________________________________________________ www.13flatFIVE.com The C++ <> REALbasic code migration specialists _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
