Re: Allowing Applications to continue after exception...

[Gregory Casamento]

Richard,

> 1. The changes to the uncaught exception handler ... as far as I can see the effect of this would be to just cause an 

> app to log the
exception and abort (assuming it falls back to the default uncaught
exception handler, or randomly 
> crash if that doesn't work ... you can't
recover from an uncaught exception, so changing the code to remove
'abort()' 
> won't let the app recover.  I would guess that the existing
behavior might be preferable to this.

I did that by accident.  I've put the code for this back in. 

> 2. The change to wrap the call to sendEvent: in an exception handler
will work though (and should mean that the 
> uncaught hander doesn't get
called for most exceptions).
> But, why not put the update of the main menu inside the handler too?
> And why not use the same user default as Apple to control this?  I
don't think we should be adding a 
> GSDebugException  default which is not
compatible with the Apple stuff, when we could equally well use the
> NSExceptionHandlerMask user 
> default and stay apple compatible.

I agree about putting the menu update into the handler too, so I've done that.  I will use the NSExceptionHandlerMask default to control this behavior, but at this point (since we don't have the ExceptionHandling framework) it's going to be very rudimentary at this point since the full functionality should be implemented in the ExceptionHandling framework.  

I will make these changes, do some more testing and commit. 

Later, GC

On Sun, Feb 8, 2009 at 12:39 AM, Richard Frith-Macdonald <address@hidden> wrote:

On 8 Feb 2009, at 04:06, Gregory Casamento wrote:

Here is the promised patch.   Please take a look and give any feedback you can.

This is simply a patch to allow the user to set whether or not they want to debug exceptions or not.  The default is NO at present so the exceptions will simply be logged as they are in Cocoa.

I am going to go ahead and commit this change fairly soon (probably early tomorrow morning) after I do more testing.  If it causes problems for anyone then we can revert it.  I know this goes a bit against what I said earlier (about sending a patch), but I would like to get this in very soon and it's easier for people to examine if it's in the repository.

1. The changes to the uncaught exception handler ... as far as I can see the effect of this would be to just cause an app to log the exception and abort (assuming it falls back to the default uncaught exception handler, or randomly crash if that doesn't work ... you can't recover from an uncaught exception, so changing the code to remove 'abort()' won't let the app recover.  I would guess that the existing behavior might be preferable to this.

2. The change to wrap the call to sendEvent: in an exception handler will work though (and should mean that the uncaught hander doesn't get called for most exceptions).
But, why not put the update of the main menu inside the handler too?
And why not use the same user default as Apple to control this?  I don't think we should be adding a GSDebugException default which is not compatible with the Apple stuff, when we could equally well use the NSExceptionHandlerMask user default and stay apple compatible.

-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)