Re: Allowing Applications to continue after exception...
What should "NSExceptionMask" be implemented as? SHould it be a boolean that determines if we should allow the application to continue or not? That is to say * NSExceptionMask = YES - report all exceptions, but continue anyway... * NSExceptionMask = NO - current behavior If so, I have a patch almost ready. I'll submit it to the group prior to committing it since a change that is this important needs to have some amount of consensus. GC On Thu, Feb 5, 2009 at 2:34 AM, Richard Frith-Macdonald < rich...@tiptree.demon.co.uk> wrote: > > On 5 Feb 2009, at 07:23, Gregory John Casamento wrote: > > 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. >> > > I'm sure David's point was that, at the moment, GNUstep limits damage where > Cocoa trashes things. It's not at all true to say that GNUstep fails and > Cocoa recovers ... more true to say that cocoa hides bugs and often gets > away with it. > > Anyway, we should implement the NSExceptionMask user default and the issue > then becomes irrelevant as we can control which behavior we want for a > particular application. > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Hello Gregory, Am Freitag, den 06.02.2009, 00:33 -0500 schrieb Gregory Casamento: > What should "NSExceptionMask" be implemented as? SHould it be a > boolean that determines if we should allow the application to continue > or not? Did you read the link that Richard provided? http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Exceptions.html http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html Table 1 Exception-handling constants and defaults values: Type of Action / Constant / Value for defaults -- Log uncaught NSExceptions / NSLogUncaughtExceptionMask / 1 Handle uncaught NSExceptions / NSHandleUncaughtExceptionMask / 2 Log system-level exceptions / NSLogUncaughtSystemExceptionMask / 4 Handle system-level exceptions / NSHandleUncaughtSystemExceptionMask / 8 Log runtime errors / NSLogUncaughtRuntimeErrorMask / 16 Handle runtime errors / NSHandleUncaughtRuntimeErrorMask / 32 > That is to say > * NSExceptionMask = YES - report all exceptions, but continue > anyway... > * NSExceptionMask = NO - current behavior That would be a GNUstep extension and in my view more confusing than the current behavior. > If so, I have a patch almost ready. I'll submit it to the group prior > to committing it since a change that is this important needs to have > some amount of consensus. That's good. Yet I must admit that I find it a bit unsettling that DBModeler (who's eomodeld files are comparatively trivial) may abort while GORM (who's gorm/nib files contain very complex relationships) my silently corrupt it's files due to bugs in third party palettes. I just want you to consider this very carefully with respect to the default setting of GORM. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Am Mittwoch, den 04.02.2009, 23:44 -0800 schrieb Matt Rice: > On Wed, Feb 4, 2009 at 9:50 PM, David Ayers wrote: > > I still believe that handling generic handling of exceptions in the > > runloop is a dangerously wrong and an implementation detail that we > > shouldn't try to be compatible with. But others may disagree. > > I definitely agree with this, but wanted to toss out another point of > view in the same vein > in an editor application, say that there is an exception when working > with a single document > (i'm seeing something in DBModeler when closing certain documents > which I haven't managed to fix yet unfortunately) > > so i'm getting an exception when an error occurs in a single document, > but the entire application crashes, now i should probably add some > exception handling somewhere (not exactly sure where, probably all > over the place...) to my app but haven't figured out where yet, but > until I do, an exception in a single document means that all open > documents close, and could potentially lose changes in other unsaved > documents which are open. Indeed, an exception could cause data corruption in a single document. It may not cause any data corruption at all. But it could also cause corruption in all documents. We simply cannot tell. DBModeler should handle Exceptions where external or internal code can reasonably be expected to raise an exception. It should not be handle "defensively" due to unimplemented / buggy code in DBModeler or GDL2 (or any other dependent code). For development I think it's fine to use: defaults write DBModeler NSExceptionHandlingMask 63 Maybe we should also log this workaround the when we crash, so that a user can also decide to use it for future crashes. But I guess that means that we need to link a against the ExceptionHandling framework (which we still need to create for GNUstep even if it merely contains this single feature for now). That way the user can set the preferred handling. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
David, It may be best for some critical applications to set the NSExceptionMask setting to manually so that they will abort at the first sign of trouble. I admit I didn't read the links immediately. I have now and it looks like that is the best way to go, although a little more work than I had originally anticipated. I understand your concerns with respect to this, but it's important that we maintain compatibility with Cocoa when and if possible. Later, GC On Fri, Feb 6, 2009 at 4:44 AM, David Ayers wrote: > Hello Gregory, > > Am Freitag, den 06.02.2009, 00:33 -0500 schrieb Gregory Casamento: > > What should "NSExceptionMask" be implemented as? SHould it be a > > boolean that determines if we should allow the application to continue > > or not? > > Did you read the link that Richard provided? > > http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Exceptions.html > > http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html > > Table 1 Exception-handling constants and defaults values: > Type of Action / Constant / Value for defaults > -- > Log uncaught NSExceptions / NSLogUncaughtExceptionMask / 1 > Handle uncaught NSExceptions / NSHandleUncaughtExceptionMask / 2 > Log system-level exceptions / NSLogUncaughtSystemExceptionMask / 4 > Handle system-level exceptions / NSHandleUncaughtSystemExceptionMask / 8 > Log runtime errors / NSLogUncaughtRuntimeErrorMask / 16 > Handle runtime errors / NSHandleUncaughtRuntimeErrorMask / 32 > > > That is to say > > * NSExceptionMask = YES - report all exceptions, but continue > > anyway... > > * NSExceptionMask = NO - current behavior > > That would be a GNUstep extension and in my view more confusing than the > current behavior. > > > If so, I have a patch almost ready. I'll submit it to the group prior > > to committing it since a change that is this important needs to have > > some amount of consensus. > > That's good. > > Yet I must admit that I find it a bit unsettling that DBModeler (who's > eomodeld files are comparatively trivial) may abort while GORM (who's > gorm/nib files contain very complex relationships) my silently corrupt > it's files due to bugs in third party palettes. > > I just want you to consider this very carefully with respect to the > default setting of GORM. > > Cheers, > David -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 6 Feb 2009, at 05:33, Gregory Casamento wrote: What should "NSExceptionMask" be implemented as? SHould it be a boolean that determines if we should allow the application to continue or not? That is to say * NSExceptionMask = YES - report all exceptions, but continue anyway... * NSExceptionMask = NO - current behavior If so, I have a patch almost ready. I'll submit it to the group prior to committing it since a change that is this important needs to have some amount of consensus. Looks good to me. I think I would prefer three options: 1) Crash / go to debugger on uncaught exception. 2) NSLog the exception and continue. 3) Pop up a modal dialog asking the user to choose between the two behaviours. Option 3 would be useful for debugging. I don't like the current behaviour, since the dialog is non-modal and the app appears to continue for a little while behind it then die, and neither button has ever actually done anything when I've clicked on it... David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Gregory Casamento wrote: What should "NSExceptionMask" be implemented as? SHould it be a boolean that determines if we should allow the application to continue or not? That is to say * NSExceptionMask = YES - report all exceptions, but continue anyway... * NSExceptionMask = NO - current behavior If so, I have a patch almost ready. I'll submit it to the group prior to committing it since a change that is this important needs to have some amount of consensus. Have a look at Apple's ExceptionHandlingFramework, which is described here: http://developer.apple.com/documentation/Cocoa/Reference/ ExceptionHandlingFramework/index.html Implementation of this framework looks very straight forward, and I guess that they simply install the defaultExceptionHandler in the event loop of NSApplication. The NSExceptionHandlingMask (not NSExceptionMask!) default is described in the accompanying guide that Richard mentioned already: http://developer.apple.com/documentation/Cocoa/Conceptual/ Exceptions/Exceptions.html In particular, see the section "Controlling a Program’s Response to Exceptions". Essentially, NSExceptionHandlingMask is a bit mask that controls whether uncaught exceptions, uncaught system exceptions, and runtime errors are logged and/or handled. The important values (quoted from the above document) are #define NSLogUncaughtExceptionMask 1 #define NSHandleUncaughtExceptionMask 2 #define NSLogUncaughtSystemExceptionMask 4 #define NSHandleUncaughtSystemExceptionMask 8 #define NSLogRuntimeErrorMask 16 #define NSLogUncaughtRuntimeErrorMask 32 Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
My test application doesn't link with the ExceptionHandling framework at all So, it looks like we have two things going on here under Cocoa/OpenStep: 1) The standard/default exception handler generally just logs the exception and continues... as illustrated by my example code. 2) The ExceptionHandling.framework allows us to handle exceptions in a more finely grained manner by replacing the standard/default exception handler with one that can talk to the delegate. (if the application links with the ExceptionHandling.framework) So it seems that implementing part 1 and 2 are not interdependent on one another. Is anyone else getting that impression? GC On Fri, Feb 6, 2009 at 10:51 AM, Wolfgang Lux wrote: > Gregory Casamento wrote: > > What should "NSExceptionMask" be implemented as? SHould it be a boolean >> that determines if we should allow the application to continue or not? >> >> That is to say >> * NSExceptionMask = YES - report all exceptions, but continue anyway... >> * NSExceptionMask = NO - current behavior >> >> If so, I have a patch almost ready. I'll submit it to the group prior to >> committing it since a change that is this important needs to have some >> amount of consensus. >> > > Have a look at Apple's ExceptionHandlingFramework, which is described here: > > http://developer.apple.com/documentation/Cocoa/Reference/ > ExceptionHandlingFramework/index.html > > Implementation of this framework looks very straight forward, and I guess > that they simply install the defaultExceptionHandler in the event loop of > NSApplication. > > The NSExceptionHandlingMask (not NSExceptionMask!) default is described in > the accompanying guide that Richard mentioned already: > > http://developer.apple.com/documentation/Cocoa/Conceptual/ > Exceptions/Exceptions.html > > In particular, see the section "Controlling a Program's Response to > Exceptions". > > Essentially, NSExceptionHandlingMask is a bit mask that controls whether > uncaught exceptions, uncaught system exceptions, and runtime errors are > logged and/or handled. The important values (quoted from the above document) > are > > #define NSLogUncaughtExceptionMask 1 > #define NSHandleUncaughtExceptionMask 2 > #define NSLogUncaughtSystemExceptionMask 4 > #define NSHandleUncaughtSystemExceptionMask 8 > #define NSLogRuntimeErrorMask 16 > #define NSLogUncaughtRuntimeErrorMask 32 > > Wolfgang > > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
The same is true for me too! I hope to have connection at FOSDEM though, for email or even real-time communication with those which couldn't come. Riccardo - Original Message - From: "Richard Frith-Macdonald" > I'll be leaving for FOSDEM tomorrow morning and won't be home again > until Monday evening. > My availability on email over that period will be very patchy. > Hope to see a few of you there. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
Excellent... have a safe trip. Let me know how things go there... and have a beer for me if you can. ;) On Fri, Feb 6, 2009 at 3:16 PM, Riccardo Mottola wrote: > The same is true for me too! > > I hope to have connection at FOSDEM though, for email or even real-time > communication with those which couldn't come. > > Riccardo > > - Original Message - > From: "Richard Frith-Macdonald" > > > > I'll be leaving for FOSDEM tomorrow morning and won't be home again > > until Monday evening. > > My availability on email over that period will be very patchy. > > Hope to see a few of you there. > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
BTW, I should be available on skype if anyone there wants to get in touch with me from the conference. On Fri, Feb 6, 2009 at 3:22 PM, Gregory Casamento wrote: > Excellent... have a safe trip. Let me know how things go there... and > have a beer for me if you can. ;) > > > On Fri, Feb 6, 2009 at 3:16 PM, Riccardo Mottola wrote: > >> The same is true for me too! >> >> I hope to have connection at FOSDEM though, for email or even real-time >> communication with those which couldn't come. >> >> Riccardo >> >> - Original Message - >> From: "Richard Frith-Macdonald" >> >> >> > I'll be leaving for FOSDEM tomorrow morning and won't be home again >> > until Monday evening. >> > My availability on email over that period will be very patchy. >> > Hope to see a few of you there. >> >> >> >> ___ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> http://lists.gnu.org/mailman/listinfo/gnustep-dev >> > > > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > ## GNUstep Chief Maintainer > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell), (301)362-9640 (Home) > > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
