On 5 Feb 2009, at 06:15, Gregory John Casamento wrote:
David,
Simply because an exception is thrown and not caught does not
necessarily mean that the application is in an unknown state.
That really depends on your use of the work 'unknown'. Obviously if
I've planned it, or if I catch it under debug and examine the stack
and data structures, then I know the state, but that's not the point.
The point is that the generic code in our library doesn't know the
state of the system and has no way of knowing what the best way to
deal with the exception is.
Indeed some applications may have come to rely on this behavior and
it makes it very difficult to port applications which do this
without refactoring.
True. Such applications are fundamentally badly designed/buggy, but
it generally doesn't win you any friends to say so.
It's not as if
As far as being "dangerously wrong" I believe it's equally wrong
(or, perhaps, worse) to have the application blow up when an
exception is easily recoverable and isn't fatal.
Yes ... but it's the application programmers responsibility to recover
from a recoverable exception. If they didn't put in any code to
recover from an exception then the enclosing code is supposed assume
that it was an unrecoverable error, because it can't know whether the
exception is truly recoverable or not. That's the whole nature of the
exception handling paradigm.
The philosophy is that, if it is possible to continue... it should
continue. It is up to the app developer to catch the exception and
take appropriate action. If it's a fatal exception, it should be up
to the developer of the application to cause the app to terminate.
That's the opposite of conventional logic for exception handling (in
which it's the developer's responsibility to do error recovery, not
their responsibility to abort).
However, if it's up to the developer of the application to cause the
app to terminate, then they should have caught the exception and
terminated the app. In neither case should the exception have reached
our code.
In truth the best behavior depends on the circumstances ... probably
it's more often good to keep running in a gui app, as there is a human
being there to notice the problem, and it's generally best to abort in
any other circumstances, to minimise the damage that might be caused.
We should NOT force the decision.
We can't help it ... we have to implement some behavior.
NEWS ... after saying all that, I actually searched for everything I
could find about exception handling in MacOS-X (to see what they
actually tell their developers to do), and there's new stuff there.
It seems that they've actually implemented the sort of user default
based control I suggested in my previous email:
See http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html#/
/apple_ref/doc/uid/20000473-BBCHGJIJ
It also sounds like they've added a whole framework for exception
handling. Duplicating that might take some time, but the basic
handling mask in the default system should be quite easy to do.
Interestingly, it seems that for secondary threads they do normal
exception handling and just terminate the thread. The catching and
logging stuff is normally done only in the main thread.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev