What does NSError do on its own, if anything?

Question

I'm looking to start putting error catches into my code, and I want to see what NSError objects do for me on their own and what I'd have to add in myself.

Looking at this SO question and the Apple Docs, it looks like all NSError does is hold onto a numeric error code, the location of the error, and a description of the error. For all three of these items, I have to specify them in my code. Then, if I want to do something like skip to the end of any methods currently being executed (that would most likely cause a crash if the app tried to run them), or display a UIAlertView telling the user there was an error, I have to specify all of that on my own as well, correct?

I'm a bit of a beginner, so is there anything else I would want to consider doing?

To clarify, I know how I would go through displaying alerts and writing gotos when I need to. I'm mostly trying to verify that it is up to me to do those things. For example, I don't want to write my own code to show an alert, if having a non-null error object would automatically create an alert, leaving my user with double alerts to sort through. — GeneralMike, Oct 26 '12 at 15:36

Sergey Kalinichenko · Accepted Answer · 2012-10-26T18:14:06.413

3

NSError is a container for error information, it does not do anything on its own. The class is designed so that different parts of your code could communicate error information to each other in a standardized way. Simply setting an error inside a method that takes NSError** does nothing - it's the responsibility of the caller to check if *error is non-nil, skip to the end of the method, display localized description, prompt the user for an action, and so on.

However, NSError is flexible enough to enable you to do all that: the caller can provide pretty much any kind of information; you can track recovery attempts, display localized messages to the user, or store additional information in the NSError object, and return it further down the call chain.

Note: Cocoa framework methods generally require that you check the direct return value before using the NSError, not checking whether the error is nil. The error is guaranteed to be valid if the method indicates failure, but it is not guaranteed to be nil for success, even if you set it to nil beforehand.

edited Oct 26 '12 at 18:14

answered Oct 26 '12 at 15:13

Sergey Kalinichenko

675,664
71
998
1,399

Thanks, the first sentence was pretty much exactly what I was looking for - calling it a "container for information" is a good way of putting it. Lots of other good info in the rest of the post too. – GeneralMike Oct 26 '12 at 15:40
Cocoa framework methods generally require that you check the direct return value before using the `NSError`, not checking whether the error is `nil`. The error is guaranteed to be valid if the method indicates failure, but it is not guaranteed to be `nil` for success, even if you set it to `nil` beforehand. – jscs Oct 26 '12 at 18:12
@JoshCaswell What an excellent comment! I copied it into the answer verbatim. Thank you very much! – Sergey Kalinichenko Oct 26 '12 at 18:14
You're welcome; glad you find it helpful. It was intended to be in response to the last sentence of your first paragraph, which seemed slightly misleading. – jscs Oct 26 '12 at 18:16

score 1 · Answer 2 · answered Oct 26 '12 at 15:08

1

NSError is provided as an encapsulation of errors. It is a good OO practice and it allows for other signatures to strongly type against it. This is much like the Exception class in Java and C#. It also allows you to create a pointer to pass into a method that takes NSError as an argument, after the method finishes, you can check NSError for conditions your application can handle.

answered Oct 26 '12 at 15:08

chrislhardin

1,705
1
26
42

Ah, so it's largely intended as a standardized object to explicitly deal with errors. I'm not too familiar with Java or C#, but I know my company has a lot of old Fortran code that will have something like `integer errorNumber = 0` and pass it around through calls, and set it to non-zero when something happens. Then there's a big select case block that will show a relevant message depending on what the number is. So NSError is pretty much a way to roll all that info into 1 bundle, instead of having to deal with it in a bunch of separate parts? – GeneralMike Oct 26 '12 at 15:55
yes sir, that is the main usage. Just imagine if you had to pass error code, message, description and stack traces all separately. It's just a simple encapsulation mechanism. Hope that cleared it up for you. – chrislhardin Oct 26 '12 at 15:57

score 1 · Answer 3 · edited Oct 26 '12 at 15:12

1

You might want to look into posting some code to help illustrate what you are trying to accomplish.

One thing you could do is, after calling the method that would populate an error object, check if the error is not nil, or evaluate the properties of the error object.

It could look something like:

-(void)someMethod {
    NSError *error;

    [self myMethod:&error];

    if ( error ) {
        // handle the error, display an alert, etc ...
    }
    else {
        // do other stuff when no error occurs
    }
}

edited Oct 26 '12 at 15:12

Carl Norum

201,810
27
390
454

answered Oct 26 '12 at 15:10

Mike D

4,788
6
42
94

I wasn't so much asking "how do I code this", more like "do I need to code this, or will it be coded for me". In hindsight, I probably should have included some code in case someone finds this later on that **is** looking for the code, but what you have here is pretty much just what I was thinking. I added a comment to my question to clarify what I was asking. – GeneralMike Oct 26 '12 at 15:45

What does NSError do on its own, if anything?

3 Answers3