Advertise here




Advertise here

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Slick's Categories - Errors

BrianSlickBrianSlick Treadmill Desk NinjaPosts: 10,676Tutorial Authors, Registered Users @ @ @ @ @ @ @ @
edited September 2012 in iOS SDK Development
I was inspired by this blog post to care more about handling errors. I'm really, really bad about doing error:nil. In an effort to do at least a bare minimum of paying attention to errors, I've come up with a few categories after scanning through one of my apps. Feel free to offer suggestions for improvement.
//  BTIErrorCategories.h

// Libraries
#import <Foundation/Foundation.h>
#import <CoreData/CoreData.h>

#pragma mark - NSFetchedResultsController Categories

@interface NSFetchedResultsController (BTIErrorAdditions)

- (BOOL)performFetchBTI;

@end

#pragma mark - NSFileManager Categories

@interface NSFileManager (BTIErrorAdditions)

- (BOOL)createDirectoryAtPathBTI:(NSString *)path withIntermediateDirectories:(BOOL)createIntermediates attributes:(NSDictionary *)attributes;
- (BOOL)removeItemAtPathBTI:(NSString *)path;
- (BOOL)setAttributesBTI:(NSDictionary *)attributes ofItemAtPath:(NSString *)path;

@end

#pragma mark - NSManagedObjectContext Categories

@interface NSManagedObjectContext (BTIErrorAdditions)

- (NSUInteger)countForFetchRequestBTI:(NSFetchRequest *)fetchRequest;
- (NSArray *)executeFetchRequestBTI:(NSFetchRequest *)fetchRequest;
- (BOOL)saveBTI;

@end
...
I'm just doing them as I find them. I suppose if I go long enough, there are a ton of methods that I'll be replacing. And then the implementation for each one is pretty similar, so here are a couple of examples:
//  BTIErrorCategories.m

#import "BTIErrorCategories.h"

#pragma mark - NSFetchedResultsController Categories

@implementation NSFetchedResultsController (BTIErrorAdditions)

- (BOOL)performFetchBTI
{
NSError *error;
BOOL isFetchSuccessful = [self performFetch:&error];
if (!isFetchSuccessful)
{
NSLog(@"ERROR: Perform Fetch: %@", [error localizedDescription]);
}

return isFetchSuccessful;
}

@end

#pragma mark - NSFileManager Categories

@implementation NSFileManager (BTIErrorAdditions)

- (BOOL)removeItemAtPathBTI:(NSString *)path
{
NSError *error;
BOOL isRemoveSuccessful = [self removeItemAtPath:path error:&error];
if (!isRemoveSuccessful)
{
NSLog(@"ERROR: Remove Item: %@", [error localizedDescription]);
}

return isRemoveSuccessful;
}
Usage and Creation

Basically each time I find a method in my code that accepts an error parameter, I head over to the documentation for that method. Copy the method declaration while leaving off the (normally) final error parameter, and paste into this file. Then decorate the method however you like, I like to add a suffix.

Then the implementation is simply what I should be doing in code already. Provide the error parameter, then respond to the error if there is one.

So now everywhere that I'm doing this:
[fetchedResultsController performFetch:nil];
...what I should in fact be doing is this:
NSError *error;
BOOL isFetchSuccessful = [fetchedResultsController performFetch:&error];
if (!isFetchSuccessful)
{
NSLog(@"ERROR: Fetch problem");
}
...and now I can do this instead:
[fetchedResultsController performFetchBTI];
So even if I'm not necessarily going to care about a particular error, at least this way I'll find out that an error is happening, and it doesn't require any extra effort on my part. I'm not cluttering up my code with tons of error handlers. If there turns out to be a problem that needs additional handling, then sure, revert back to the normal, full, method and handle the error manually. But this way, I keep the code simpler, and I can still get flagged about issues if they happen.
Professional iOS App Development. Available for hire.
BriTer Ideas LLC - WWW | Facebook | Twitter | LinkedIn

BTIKit | BTICoreDataKit | SlickShopper 2 | Leave a PayPal donation
Sign In or Register to comment.