Graphics Programs Reference
In-Depth Information
ror
for a human-readable description of the error. This is something you can show to the
user or print to a debug console.
Error objects also have
code
and
domain
properties. The code is an integer representing
the error. The domain represents the error domain. For example, not having permission to
write to a directory results in error code 513 in error domain
NSCocoaErrorDomain
.
Each domain has its own set of error codes, and codes within different domains can have
the same integer value, so an error is uniquely specified by its code and error domain. You
can check out the error codes for the
NSCocoaErrorDomain
in the file
Founda-
tion/FoundationErrors.h
.
The syntax for getting back an
NSError
instance is a little strange. An error object is
only created if an error occurred; otherwise, there is no need for the object. When a meth-
od can return an error through one of its arguments, you create a local variable that is a
pointer to an
NSError
object. Notice that you don't instantiate the error object - that is
the job of the method you are calling. Instead, you pass the
address
of your pointer vari-
able (
&err
) to the method that might generate an error. If an error occurs in the imple-
mentation of that method, an
NSError
instance is created, and your pointer is set to
point at that new object. If you don't care about the error object, you can always pass
nil
.
Sometimes you want to show the error to the user. This is typically done with an
UIAlertView
:
NSString *x = [[NSString alloc] initWithContentsOfFile:@"/some/path/file"
encoding:NSUTF8StringEncoding
error:&err];
if (!x) {
UIAlertView *a = [[UIAlertView alloc] initWithTitle:@"Read Failed"
message:[err localizedDescription]
delegate:nil
cancelButtonTitle:@"OK"
otherButtonTitles:nil];
[a show];
}
Figure 14.7 UIAlertView
