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: Gregory Casamento
Subject: Re: Allowing Applications to continue after exception...
Date: Fri, 6 Feb 2009 09:52:55 -0500

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 <address@hidden> 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
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)


reply via email to

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