Allowing Applications to continue after exception...
In some cases on Mac OS X I have observed that exceptions which are not fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change the logic which deals with exceptions to add a "continue" button and only show the panel when the application is running in debug mode. This would allow the application to continue when recovery is possible. Does anyone have any thoughts on this? Later, GC -- 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 4 Feb 2009, at 18:53, Gregory Casamento wrote: In some cases on Mac OS X I have observed that exceptions which are not fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change the logic which deals with exceptions to add a "continue" button and only show the panel when the application is running in debug mode. This would allow the application to continue when recovery is possible. Does anyone have any thoughts on this? I think the panel is shown when there is an UNCAUGHT exception. If the exception has not been caught, there is nowhere to return to and no way to continue ... so adding a continue button and returning from the uncaught exception handler would not allow the application to continue. If you want an exception to not be fatal, you have to write code to handle it and continue. Sometimes you might think you can continue running, but know that the app probably won't be doing what the user expects. In this situation it makes sense to display an alert panel explaining the nature of the problem, and allow the user to choose between continuing and cleanly terminating. This however is a very different case from the panel shown when the uncaught exception handler is called. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On Wed, Feb 4, 2009 at 11:14 AM, Richard Frith-Macdonald wrote: > > On 4 Feb 2009, at 18:53, Gregory Casamento wrote: > >> In some cases on Mac OS X I have observed that exceptions which are not >> fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change >> the logic which deals with exceptions to add a "continue" button and only >> show the panel when the application is running in debug mode. This would >> allow the application to continue when recovery is possible. >> >> Does anyone have any thoughts on this? > > I think the panel is shown when there is an UNCAUGHT exception. > If the exception has not been caught, there is nowhere to return to and no > way to continue ... so adding a continue button and returning from the > uncaught exception handler would not allow the application to continue. > > If you want an exception to not be fatal, you have to write code to handle > it and continue. > > Sometimes you might think you can continue running, but know that the app > probably won't be doing what the user expects. In this situation it makes > sense to display an alert panel explaining the nature of the problem, and > allow the user to choose between continuing and cleanly terminating. This > however is a very different case from the panel shown when the uncaught > exception handler is called. > > there might be an handler in the NSApplication -run method which allows the runloop to continue iterating... i seem to recall an old version of openstep doing something to this effect with uncaught exceptions, didn't show a panel, or NSLog anything, or abort unless of course i was using NSAssert, and it was doing something with the c preprocessor to get rid of my NSAsserts, which seems possible :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
This is what I was thinking... the reason I'm thinking about this is because I am working on porting a few apps and exception which show up in the log on Mac OS X cause GNUstep to die. GC On Wed, Feb 4, 2009 at 2:52 PM, Matt Rice wrote: > On Wed, Feb 4, 2009 at 11:14 AM, Richard Frith-Macdonald > wrote: > > > > On 4 Feb 2009, at 18:53, Gregory Casamento wrote: > > > >> In some cases on Mac OS X I have observed that exceptions which are not > >> fatal on Mac sometimes ARE fatal on GNUstep. I believe we should > change > >> the logic which deals with exceptions to add a "continue" button and > only > >> show the panel when the application is running in debug mode. This > would > >> allow the application to continue when recovery is possible. > >> > >> Does anyone have any thoughts on this? > > > > I think the panel is shown when there is an UNCAUGHT exception. > > If the exception has not been caught, there is nowhere to return to and > no > > way to continue ... so adding a continue button and returning from the > > uncaught exception handler would not allow the application to continue. > > > > If you want an exception to not be fatal, you have to write code to > handle > > it and continue. > > > > Sometimes you might think you can continue running, but know that the app > > probably won't be doing what the user expects. In this situation it > makes > > sense to display an alert panel explaining the nature of the problem, and > > allow the user to choose between continuing and cleanly terminating. > This > > however is a very different case from the panel shown when the uncaught > > exception handler is called. > > > > > > there might be an handler in the NSApplication -run method which > allows the runloop to continue iterating... > i seem to recall an old version of openstep doing something to this > effect with uncaught exceptions, didn't show a panel, or NSLog > anything, or abort unless of course i was using NSAssert, and it was > doing something with the c preprocessor to get rid of my NSAsserts, > which seems possible :) > -- 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 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that exceptions which are
not fatal on Mac sometimes ARE fatal on GNUstep. I believe we
should change the logic which deals with exceptions to add a
"continue" button and only show the panel when the application is
running in debug mode. This would allow the application to
continue when recovery is possible.
Does anyone have any thoughts on this?
The OS X behaviour appears to be for each runloop iteration to be
wrapped in a @try{} block with the exception being NSLog'd if it
occurs during the runloop. This is quite convenient for debugging,
since you can just read the log and find out where the exception
happened, without having to
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
I definitely think we should implement something similar. It would help a
great deal with some porting efforts.
On Wed, Feb 4, 2009 at 3:03 PM, David Chisnall wrote:
> On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
>
> In some cases on Mac OS X I have observed that exceptions which are not
>> fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change
>> the logic which deals with exceptions to add a "continue" button and only
>> show the panel when the application is running in debug mode. This would
>> allow the application to continue when recovery is possible.
>>
>> Does anyone have any thoughts on this?
>>
>
> The OS X behaviour appears to be for each runloop iteration to be wrapped
> in a @try{} block with the exception being NSLog'd if it occurs during the
> runloop. This is quite convenient for debugging, since you can just read
> the log and find out where the exception happened, without having to
>
> 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 Feb 4, 2009, at 1:23 PM, Gregory Casamento wrote:
I definitely think we should implement something similar. It would
help a great deal with some porting efforts.
On Wed, Feb 4, 2009 at 3:03 PM, David Chisnall
wrote:
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that exceptions which are
not fatal on Mac sometimes ARE fatal on GNUstep. I believe we
should change the logic which deals with exceptions to add a
"continue" button and only show the panel when the application is
running in debug mode. This would allow the application to
continue when recovery is possible.
Does anyone have any thoughts on this?
The OS X behaviour appears to be for each runloop iteration to be
wrapped in a @try{} block with the exception being NSLog'd if it
occurs during the runloop. This is quite convenient for debugging,
since you can just read the log and find out where the exception
happened, without having to
David
Yes, I've found it useful for debugging, particularly when you've just
implemented a bunch of things. Just logging the exception allows you
to see how the app operates in general, even it the behavior is off.___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 4 Feb 2009, at 20:23, Gregory Casamento wrote:
I definitely think we should implement something similar. It would
help a great deal with some porting efforts.
On Wed, Feb 4, 2009 at 3:03 PM, David Chisnall
wrote:
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that exceptions which are
not fatal on Mac sometimes ARE fatal on GNUstep. I believe we
should change the logic which deals with exceptions to add a
"continue" button and only show the panel when the application is
running in debug mode. This would allow the application to
continue when recovery is possible.
Does anyone have any thoughts on this?
The OS X behaviour appears to be for each runloop iteration to be
wrapped in a @try{} block with the exception being NSLog'd if it
occurs during the runloop. This is quite convenient for debugging,
since you can just read the log and find out where the exception
happened, without having to
Logging any exception in the application main runloop ought to be
pretty easy to implement.
Would we wnat to look at other bits of code running event loops, and
trap exceptions there too?
___
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:52 -0500 schrieb Gregory Casamento: > The attached test program does not crash on Mac OS X when the button > is pressed, but does crash on GNUstep. The button calls the "action:" > method in Controller which immediately throws an exception. > > I believe this confirms that GNUstep's behavior is inconsistent with > Cocoa. I can test on OpenStep, but I suspect that the behavior is > the same there as it is on Cocoa. FWIW, IIRC this inconsistency was intentional an I believe for a very good reason. I thought we had documented it at the time but I can't dig it up easily right now. An uncaught exception indicates that the application is in an undefined state. For certain type of applications (like viewers) this can be ignored. For editor application this could mean that the document being edited could be corrupted and saving it cause data corruption. This thread is the only reference I found in which we suggested some type of "Developer-Mode" which indicates that "I know what I'm doing, let me debug, will you?!". http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html 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. 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, Simply because an exception is thrown and not caught does not necessarily mean that the application is in an unknown state. 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. 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. 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. We should NOT force the decision. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: David Ayers To: Gregory Casamento Cc: Adam Fedor ; Developer GNUstep Sent: Thursday, February 5, 2009 12:50:15 AM Subject: Re: Allowing Applications to continue after exception... Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento: > The attached test program does not crash on Mac OS X when the button > is pressed, but does crash on GNUstep. The button calls the "action:" > method in Controller which immediately throws an exception. > > I believe this confirms that GNUstep's behavior is inconsistent with > Cocoa. I can test on OpenStep, but I suspect that the behavior is > the same there as it is on Cocoa. FWIW, IIRC this inconsistency was intentional an I believe for a very good reason. I thought we had documented it at the time but I can't dig it up easily right now. An uncaught exception indicates that the application is in an undefined state. For certain type of applications (like viewers) this can be ignored. For editor application this could mean that the document being edited could be corrupted and saving it cause data corruption. This thread is the only reference I found in which we suggested some type of "Developer-Mode" which indicates that "I know what I'm doing, let me debug, will you?!". http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html 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. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 5 Feb 2009, at 05:50, David Ayers wrote: http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/ msg00092.html 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. Well I agree that it's obviously dangerously wrong ... but I'm not sure that means we shouldn't do it anyway. Pragmatically, it seems like the vast majority of exceptions do not indicate anything very harmful, so continuing is not a problem for those cases, so compatibility might generally make sense. What we could do is make the behavior selectable (with a user default for instance), and use it as a selling points that we can switch applications over to a 'secure' mode where they won't screw up like Apple ones might. One more thing to note ... it's not as simple as just looking at the case of catching exceptions in the application's event loop. GNUstep- base is already broken in this way in that it's Apple compatible in catching/logging exceptions inside timers and notification handlers (possibly other places too I guess). This has actually bitten me once ... where an error in a timer meant that we got a huge logfile generated, filling the disc and bringing an entire server down because the process kept running and our monitoring software therefore didn't alert us of the error. In this case, not being Apple compatible would have saved us half an hour of downtime, which is important when you are running 24x7 servers. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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/2473-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
Re: Allowing Applications to continue after exception...
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 To: Gregory John Casamento Cc: David Ayers ; Gregory Casamento ; Adam Fedor ; Developer GNUstep 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/2473-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
Re: Allowing Applications to continue after exception...
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On Wed, Feb 4, 2009 at 9:50 PM, David Ayers wrote: > Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento: >> The attached test program does not crash on Mac OS X when the button >> is pressed, but does crash on GNUstep. The button calls the "action:" >> method in Controller which immediately throws an exception. >> >> I believe this confirms that GNUstep's behavior is inconsistent with >> Cocoa. I can test on OpenStep, but I suspect that the behavior is >> the same there as it is on Cocoa. > > FWIW, IIRC this inconsistency was intentional an I believe for a very > good reason. I thought we had documented it at the time but I can't dig > it up easily right now. > > An uncaught exception indicates that the application is in an undefined > state. For certain type of applications (like viewers) this can be > ignored. For editor application this could mean that the document being > edited could be corrupted and saving it cause data corruption. > > This thread is the only reference I found in which we suggested some > type of "Developer-Mode" which indicates that "I know what I'm doing, > let me debug, will you?!". > > http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html > > 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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: Allowing Applications to continue after exception...
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.
Later, GC
On Fri, Feb 6, 2009 at 2:40 PM, Gregory Casamento
wrote:
> 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)
>
>
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)
Index: Source/NSApplication.m
===
--- Source/NSApplication.m (revision 27805)
+++ Source/NSApplication.m (working copy)
@@ -126,6 +126,7 @@
[exception raise];
}
+ /*
retVal = GSRunExceptionPanel
([NSString stringWithFormat: _(@"Critical Error in %@"),
[[NSProcessInfo processInfo] processName]],
@@ -137,18 +138,19 @@
#else
nil);
#endif
+ */
/* The user wants to abort */
if (retVal == NSAlertDefault)
{
/* The following will raise again the exception using the base
library exception handler */
- [exception raise];
+ // [exception raise];
}
else
{
/* Debug button: abort so we can trace the error in gdb */
- abort();
+ // abort();
}
}
@@ -1378,7 +1380,8 @@
{
NSEvent *e;
id distantFuture = [NSDate distantFuture]; /* Cache this, safe */
-
+ BOOL debug = [[NSUserDefaults standardUserDefaults] boolForKey: @"GSDebugException"];
+
if (_runLoopPool != nil)
{
[NSException raise: NSInternalInconsistencyException
@@ -1409,16 +1412,31 @@
IF_NO_GC(_runLoopPool = [arpClass new]);
e = [self nextEventMatchingMask: NSAnyEventMask
- untilDate: distantFuture
- inMode: NSDefaultRunLoopMode
- dequeue: YES];
-
+ untilDate: distantFuture
+ inMode: NSDefaultRunLoopMode
+ dequeue: YES
Re: Allowing Applications to continue after exception...
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
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 < rich...@tiptree.demon.co.uk> 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) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
I've implemented default for the unhandled exceptions. Please take a look at the code in the repository and let me know if you have any feedback. On Sun, Feb 8, 2009 at 1:29 AM, Gregory Casamento wrote: > 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 < > rich...@tiptree.demon.co.uk> 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) > > -- 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 8 Feb 2009, at 06:39, Richard Frith-Macdonald 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. Actually, I take it back ... maybe we can recover from an uncaught exception. Problem is ... if we are using native exceptions ... by the time the uncaught handler is called we have unwound the stack entirely and the program has no way to continue running. But maybe the native handling code can actually cope with that (or be changed to do that). Not sure where the stack pointer and program counter end up if we are using old-fashioned exceptions. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 8 Feb 2009, at 06:47, Richard Frith-Macdonald wrote:
Actually, I take it back ... maybe we can recover from an uncaught
exception.
Problem is ... if we are using native exceptions ... by the time the
uncaught handler is called we have unwound the stack entirely and
the program has no way to continue running. But maybe the native
handling code can actually cope with that (or be changed to do that).
I've been doing personality function hacking recently, so I'd be happy
to take a look at this if it's desired.
When the stack is unwound by native ('zero-cost') exceptions, the
unwind library calls the personality function twice for each frame.
The first time is to find the landing pad, the second time is to
perform the unwinding (call cleanup code in each intervening frame and
then continue unwinding).
For a while, I've been pondering adding the Étoilé resumable exception
stuff to the unwinding system. This would call the unhandled
exception function at the top of the stack, before unwinding, and
allow it to either call _Unwind_Resume() or continue, depending on the
exception.
Not sure where the stack pointer and program counter end up if we
are using old-fashioned exceptions.
This is not so difficult. I described it in this paper:
http://www.swan.ac.uk/compsci/research/reports/2008/CSR14-2008.pdf
Basically, you call the uncaught exception handler from [NSException -
raise] and let it to decide whether to unwind the stack or not.
In the general case, there's not much you can do other than pop up a
dialog saying 'Do you want to ignore this exception?' and that's
likely to cause things to break.
So, it is possible, but I'm not sure it's actually a good idea...
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 8 Feb 2009, at 11:42, David Chisnall wrote:
On 8 Feb 2009, at 06:47, Richard Frith-Macdonald wrote:
Actually, I take it back ... maybe we can recover from an uncaught
exception.
Problem is ... if we are using native exceptions ... by the time
the uncaught handler is called we have unwound the stack entirely
and the program has no way to continue running. But maybe the
native handling code can actually cope with that (or be changed to
do that).
I've been doing personality function hacking recently, so I'd be
happy to take a look at this if it's desired.
When the stack is unwound by native ('zero-cost') exceptions, the
unwind library calls the personality function twice for each frame.
The first time is to find the landing pad, the second time is to
perform the unwinding (call cleanup code in each intervening frame
and then continue unwinding).
For a while, I've been pondering adding the Étoilé resumable
exception stuff to the unwinding system. This would call the
unhandled exception function at the top of the stack, before
unwinding, and allow it to either call _Unwind_Resume() or continue,
depending on the exception.
It sounds like a good thing to have the option of resuming, even
though it's generally not advisable.
Do you have a patch for gcc/libobjc which would allow that?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 22 Feb 2009, at 10:24, Richard Frith-Macdonald wrote:
On 8 Feb 2009, at 11:42, David Chisnall wrote:
On 8 Feb 2009, at 06:47, Richard Frith-Macdonald wrote:
Actually, I take it back ... maybe we can recover from an uncaught
exception.
Problem is ... if we are using native exceptions ... by the time
the uncaught handler is called we have unwound the stack entirely
and the program has no way to continue running. But maybe the
native handling code can actually cope with that (or be changed to
do that).
I've been doing personality function hacking recently, so I'd be
happy to take a look at this if it's desired.
When the stack is unwound by native ('zero-cost') exceptions, the
unwind library calls the personality function twice for each
frame. The first time is to find the landing pad, the second time
is to perform the unwinding (call cleanup code in each intervening
frame and then continue unwinding).
For a while, I've been pondering adding the Étoilé resumable
exception stuff to the unwinding system. This would call the
unhandled exception function at the top of the stack, before
unwinding, and allow it to either call _Unwind_Resume() or
continue, depending on the exception.
It sounds like a good thing to have the option of resuming, even
though it's generally not advisable.
Do you have a patch for gcc/libobjc which would allow that?
It won't require patching gcc, just libobjc. I don't have a patch
currently, but I can probably create one fairly easily. It just
requires adding an optional trampoline in the throw function that will
bounce the exception out before unwinding the stack.
The current code in Étoilé allows exceptions to be either resumed or
restarted. Restarting jumps back to the start of the exception-
handling block and lets the code try again. This is currently done in
a really messy way. Ideally I'd want to make sure that the compiler
inserts an entry into the DWARF table pointing to the start of this
block and then let the unwind library walk back up the stack to find
it. This is a much bigger change, and one I won't have time to do for
a little while.
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 22 Feb 2009, at 12:42, David Chisnall wrote: It sounds like a good thing to have the option of resuming, even though it's generally not advisable. Do you have a patch for gcc/libobjc which would allow that? It won't require patching gcc, just libobjc. I don't have a patch currently, but I can probably create one fairly easily. It just requires adding an optional trampoline in the throw function that will bounce the exception out before unwinding the stack. Yes please ... I'd love to try that out. The current code in Étoilé allows exceptions to be either resumed or restarted. Restarting jumps back to the start of the exception- handling block and lets the code try again. This is currently done in a really messy way. Ideally I'd want to make sure that the compiler inserts an entry into the DWARF table pointing to the start of this block and then let the unwind library walk back up the stack to find it. This is a much bigger change, and one I won't have time to do for a little while. I'm not sure about that ... it's certainly not needed by GNUstep and, while I can see the appeal, I can't think of any systems that actually allow re-execution of the 'try' block, so this would not fit into normal coding paradigms. What I'm really concerned about at the moment is trying to get code into the gcc distribution before the next release which would let me properly implement the Openstep/MacOS-X exception handling API when using objc native exceptions. It looks like that's just a function to set an uncaught exception handler. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 22 Feb 2009, at 12:58, Richard Frith-Macdonald wrote:
On 22 Feb 2009, at 12:42, David Chisnall wrote:
It sounds like a good thing to have the option of resuming, even
though it's generally not advisable.
Do you have a patch for gcc/libobjc which would allow that?
It won't require patching gcc, just libobjc. I don't have a patch
currently, but I can probably create one fairly easily. It just
requires adding an optional trampoline in the throw function that
will bounce the exception out before unwinding the stack.
Yes please ... I'd love to try that out.
The same functionality, with a less elegant implementation, is
provided by ETException. There are a couple of example use-cases in
this paper:
http://www.swan.ac.uk/compsci/research/reports/2008/CSR14-2008.pdf
The current code in Étoilé allows exceptions to be either resumed
or restarted. Restarting jumps back to the start of the exception-
handling block and lets the code try again. This is currently done
in a really messy way. Ideally I'd want to make sure that the
compiler inserts an entry into the DWARF table pointing to the
start of this block and then let the unwind library walk back up
the stack to find it. This is a much bigger change, and one I
won't have time to do for a little while.
I'm not sure about that ... it's certainly not needed by GNUstep
and, while I can see the appeal, I can't think of any systems that
actually allow re-execution of the 'try' block, so this would not
fit into normal coding paradigms.
It's common in Lisp, and supported by a few Smalltalk systems.
What I'm really concerned about at the moment is trying to get code
into the gcc distribution before the next release which would let me
properly implement the Openstep/MacOS-X exception handling API when
using objc native exceptions. It looks like that's just a function
to set an uncaught exception handler.
Adding an uncaught exception handler is a bit different. This, in
Cocoa, doesn't allow you to resume from the exception, it just lets
you tidy up before the program exits. You can achieve exactly the
same functionality without modifying the compiler or runtime by
implementing your main function like this:
int main(int argc, char **argv)
{
int ret = -1;
@try
{
ret = retreal_main(argc, argv);
}
@catch (id e)
{
NSUncaughtExceptionHandler *h = NSGetUncaughtExceptionHandler();
if (h != (NSUncaughtExceptionHandler*)0)
{
h(e);
}
}
return ret;
}
I believe you should be able to use GNUstep's existing fake main code
for this. If you don't want to do this, then I could add a hack to
the personality function to do something equivalent. Unfortunately,
like most of the rest of GNU libobjc, the unwind code is typical GNU
code, being an almost unreadable mess of #ifdefs with no clear
separation of concerns in a coding convention designed for minimal
readability. The version I'm using seems to be using GNUstep make and
doesn't compile the exception handling stuff. I'll grab a copy of the
trunk version and see if it's any better.
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
