[self devStuff];

In the project I’m currently working on, I want to set the audio session correctly because in BedtimeStoriesCollection sometimes the users complain about not having sound at all. Since one of the things that I’m NOT doing is set the audio session, maybe it can be the root of the problem.

Either way, since this new app is heavily based on sound, let’s do the things as it should. One of the events that I was having some issues dealing with was the interruption notification caused either by a phone call or a Calendar event. If the sounds were being played by an AVAudioPlayer instance there would be no question whatsoever because the framework is responsible for setting the session active after the interruption ends. But with Audio Units that’s not the case so you must explicitly set the session active again, after the end of interruption:       

NSError *endInterruptionError = nil;

I will soon find out as I'm about to start working on this part for my newest iOS project...

Exceptions (represented by NSException objects) are for programming errors, such as an array index that is out of bounds or an invalid method argument. User-level errors (represented byNSError objects) are for runtime errors, such as when a file cannot be found or a string in a certain encoding cannot be read. Conditions giving rise to exceptions are due to programming errors; you should deal with these errors before you ship a product. Runtime errors can always occur, and you should communicate these (via NSError objects) to the user in as much detail as is required.

from here

Sometimes we need to go back to the basics. If possible don't use @try/@catch, instead create a NSError instance and return it by reference, such as: