gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Allowing Applications to continue after exception...


From: Richard Frith-Macdonald
Subject: Re: Allowing Applications to continue after exception...
Date: Thu, 5 Feb 2009 06:49:54 +0000


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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]