At 9:19 PM -0400 8/21/06, Charles Yeomans wrote:
Is a ThreadEndException like an EndException; that is, something we
shouldn't typically be catching or logging?
Yes, exactly.
I had this discussion with Aaron over on the forum and he said that
we should only catch the specific exceptions we are prepared to
handle. He advised against unfiltered exception handling.
http://forums.realsoftware.com/viewtopic.php?t=6385&highlight=
I had an exception handler in a thread and discovered that I couldn't
kill the thread since my exception handler caught the
ThreadEndException. He said this was supposed to be documented but
wasn't.
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
FrameworkException only in debug builds but enable UserCodeExceptions
in all builds.
Does anyone else have thoughts on how prioritizing exceptions should
work? Any Feature Request IDs???
Thanks,
Joe Huber
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
