Hi Fred, yes -- duplication is precisely the reason why I was asking :-)
I'll keep the change only local, then. Since I test with stock GNUstep apps, I'd have to change each app individually. I obviously would prefer not doing that. But, it would make sense to rethink how we can get the message output as soon as possible, precisely because of possible bugs in theme, back or even appkit. Maybe we can flag the exception as already printed out? Maybe we can ask -base to do its logging first? On Sat, Aug 3, 2013 at 3:40 PM, Fred Kiefer <[email protected]> wrote: > This setting only affects exceptions that occure during event processing > in the run loop. If the exception you get comes from the run loop, this > mechanism should work and if it doesn't, we should fix that. > > At the moment you have a very specific situation where the alert isn't > working itself, in this situation, getting a log message will be really > helpful. In all other cases it would just dublicate the message in the > alert. For that reason I would suggest you make this change locally and > don't commit it. Or you set your own exception handler in you test code to > get full control. > > Fred > > On the road > > Am 03.08.2013 um 15:14 schrieb Ivan Vučica <[email protected]>: > > Hi Fred, > > On Fri, Aug 2, 2013 at 4:50 PM, Fred Kiefer <[email protected]> wrote: > >> >> please have a look at this method in NSApplication: >> >> - (void) _handleException: (NSException *)exception >> >> As you can see it gets the mask for exception handling from the >> defaults. My current setting there is 3, which means I get a log and the >> exception ends up in a panel. This is the best setting for a development >> environment, but not what you want on a user desktop. >> > > I've also looked at this method, since AppKit's interception of exceptions > complicates debugging -back. > > It looks like setting NSExceptionHandlerMask to 1 in NSGlobalDomain.plistdoes > not prevent AppKit's exception handler from kicking in (and trying to > show the alert panel), and setting it to 0 does not help either. > > Nothing is logged in my case before the alert display code in > _NSAppKitUncaughtExceptionHandler() kicks in. > > I propose a change to _NSAppKitUncaughtExceptionHandler() to add > NSLog(@"Unhandled > exception: %@", exception); just before the call to GSRunExceptionPanel() (but > after the possible bailing out in case current context is nil). > > Any objections? > > I'll be happy to commit the following diff: > > Index: Source/NSApplication.m > =================================================================== > --- Source/NSApplication.m (revision 36941) > +++ Source/NSApplication.m (working copy) > @@ -131,6 +131,8 @@ > [exception raise]; > } > > + NSLog(@"Unhandled exception: %@", exception); > + > retVal = GSRunExceptionPanel > ([NSString stringWithFormat: _(@"Critical Error in %@"), > [[NSProcessInfo processInfo] processName]], > > > -- > Ivan Vučica > [email protected] > > _______________________________________________ > > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > -- Ivan Vučica [email protected]
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
