[Dalgo]

I can't seem to be able to catch an exception. I save NSColor objects in my preferences and I thought that when my program starts I should test reading them to make sure that the user didn't mess with the preferences and if an exception is raised I'd simply remove that object from the preferences and use the default. My problem is that my exceptions are never caught. From within the init method of one of my classes I have this:

NS_DURING
[NSUnarchiver unarchiveObjectWithData: [[NSUserDefaults standardUserDefaults] objectForKey:@"colorWell1"]];
[NSUnarchiver unarchiveObjectWithData: [[NSUserDefaults standardUserDefaults] objectForKey:@"colorWell2"]];
[NSUnarchiver unarchiveObjectWithData: [[NSUserDefaults standardUserDefaults] objectForKey:@"selectionColorWell"]];
NS_HANDLER
NSBeep();
if ([[localException name] isEqualToString:@"NSInternalInconsistencyException "])
NSBeep();
else
//[localException raise];
NS_ENDHANDLER

I did that just to see if it worked. I'd make it beep. Now, I corrupted my prefs file to see what would happen and when the exception is raised it never goes to NS_HANDLER. The program quits and displays:

** Uncaught exception: <NSInternalInconsistencyException&gt ; Invalid parameter not satisfying: aColor != nil

So.. what am I doing wrong. I want to known if it has an exception so I can fix it. I don't want it to crash.

[lindberg]

By the looks of it, I don't think the exception is happening during the code you posted. The exception is in the style of a failed assertion, meaning there was a nil argument passed to a method that requires a non-nil argument. It doesn't look like any of your code there would actually call such a method, though I could be wrong.

The easiest thing to do is to run the app under gdb, set a breakpoint on the -raise method (type "break -[NSException raise]" or "b raise" and pick the right one), and look at the backtrace when the breakpoint is hit. That should tell you where the error is.

[Dalgo]

Well, if I comment out everything from NS_DURING to NS_ENDHANDLER then it doesn't crash. I guess that I'll try what you said and see what happens, though...

[gregomni]

It looks like what is happening is the unarchiver call is returning nil instead of a color or raising. Then when you try to actually set that color on the color well, the color well is raising an exception that it can't display a nil color.

It'd be best to confirm that using the debugger as lindberg suggests...

[Dalgo]

Actually I'm not setting the color in the well there, I'm reading the data from the user defaults, which I corrupted on purpose, and I am trying to unarchive the corrupt data (although you can see that I'm not string the returned value anywhere.) In this case I want to get the exception, it's just that I don't know why it's not catching it. I tried doing a backtrace and it gave me some strange error that it couldn't do a backtrace. I'll do it again and post the error message later. The line of code that is raising the exception IS after NS_DURING, that much I did get from the debugger, so I don't really know what's wrong. I did run it after giving it good data and no exception was raised , as expected, so it IS the bad data that I gave it that is causing the exception.

[gregomni]

Something I just noticed from your code sample that could be a problem. Since you commented out a line in your handler, the code is going to be compiled as:

if ([[localException name] ...])
NSBeep();
else
NS_ENDHANDLER

That is, the end handler is part of the else clause of your if statement, which could cause who knows what havoc.

[Dalgo]

Actually, I commented that out after it didn't work the first time. I was afraid that maybe it failed that if statement. I don't know why the compiler didn't give me an error with that, though. I haven't posted what I get when I try to do a backtrace yet because I have been working on another part of my program.when I finish that part, I'll get back to messing with exceptions.