Re: NSException category?
Re: NSException category?
- Subject: Re: NSException category?
- From: Doug Hill <email@hidden>
- Date: Thu, 06 Feb 2014 11:36:48 -0800
I don't see any such behavior in the Objective-C language reference. Feel free to read those chapters for more information. :) There's also an Apple document "Introduction to Exception Programming Topics for Cocoa" which has some good information.
Doug Hill
On Feb 6, 2014, at 11:08 AM, Carl Hoefs <email@hidden> wrote:
> Doug,
>
> If I add a "@throw e;" in the @catch block, would that have the effect of "tagging" the unhandled exceptions with my info context, assuming I could add my own userInfo to it?
>
> -Carl
>
> On Feb 6, 2014, at 11:57 AM, Doug Hill <email@hidden> wrote:
>
>> Carl,
>>
>> In your case below, I don't see the value of adding any info to the exception as it's just been caught and won't be seen by anyone else. Since your exception handler knows about this special error condition, if you want to propagate this exception, just create a new exception object of your custom class MyUnsupportedSessionResolutionException with whatever user info you want and re-throw that one.
>>
>> Good luck!
>>
>> Doug Hill
>>
>> On Feb 6, 2014, at 10:44 AM, Carl Hoefs <email@hidden> wrote:
>>
>>> I would like to be able to add additional context info to certain exceptions that the system might generate. Since NSException's userInfo dict is nil in such cases it would be convenient to add an error context dict to the exception and then handle/display it.
>>>
>>> @try {
>>> ...;
>>> }
>>> @catch (NSException *e) {
>>> e.userInfo = [NSDictionary dictionaryWithObject:@"Unsupported session resolution"
>>> andKey:@"Context"];
>>> --> No setter method "setUserInfo:" for assignment to property
>>> [ self showException: e ];
>>> }
>>> @finally {
>>> ...;
>>> }
>>>
>>> Unfortunately I can't just add my own userInfo dict onto the exception, as there is no setter for it by default. Would it be heresy to create an NSException category to implement the -setUserInfo: method to do this? What is a better way to handle this?
>>>
>>> -Carl
>>>
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden