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 <ay...@fsfe.org> 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
