Richard,

"True.  Such applications are fundamentally badly designed/buggy, but it 
generally doesn't win you any friends to say so."

 
That could be true, but I don't believe, however, that GNUstep should fail 
where Cocoa recovers.

The fact of the matter is that differences like this fundamentally impact 
portability between Cocoa/OpenStep and GNUstep.

"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."

Agreed.

Gregory Casamento -- Principal Consultant - OLC, Inc 
# GNUstep Chief Maintainer




________________________________
From: Richard Frith-Macdonald <rich...@tiptree.demon.co.uk>
To: Gregory John Casamento <greg_casame...@yahoo.com>
Cc: David Ayers <ay...@fsfe.org>; Gregory Casamento <greg.casame...@gmail.com>; 
Adam Fedor <fe...@qwestoffice.net>; Developer GNUstep <gnustep-dev@gnu.org>
Sent: Thursday, February 5, 2009 1:49:54 AM
Subject: Re: Allowing Applications to continue after exception...


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

Reply via email to