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
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
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,
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
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
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
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
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
greg.casame...@gmail.comwrote:
Richard,
1. The changes to the uncaught exception handler ...
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.
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
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?
Am Mittwoch, den 04.02.2009, 23:44 -0800 schrieb Matt Rice:
On Wed, Feb 4, 2009 at 9:50 PM, David Ayers ay...@fsfe.org 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
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
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
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
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
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
On Wed, Feb 4, 2009 at 11:14 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk 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
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 ratm...@gmail.com wrote:
On Wed, Feb 4, 2009 at 11:14 AM,
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
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 thera...@sucs.org wrote:
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that
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 thera...@sucs.org
wrote:
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
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 thera...@sucs.org
wrote:
On 4 Feb 2009, at 18:53, Gregory Casamento 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
From: David Ayers ay...@fsfe.org
To: Gregory Casamento greg.casame...@gmail.com
Cc: Adam Fedor fe...@qwestoffice.net; Developer GNUstep gnustep-dev@gnu.org
Sent: Thursday, February 5, 2009 12:50:15 AM
Subject: Re: Allowing Applications to continue after exception...
Am Mittwoch, den
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
On Wed, Feb 4, 2009 at 9:50 PM, David Ayers ay...@fsfe.org 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
27 matches
Mail list logo
