.NET error handling: try/catch VS event VS return-value/status-fields

Question

I'm at a very crucial cross road in my cross-platform mobile app development right now and could really use some expertise (like woah).

To give some context (which may help in answering I hope), I'm developing a mobile app in .NET based on the handy-dandy MonoCross framework, using VS2010U (not MonoDevelop, yet, that is for IOS). The first targeted platform is Android, then onto the IOS and Windows Phone "ports" (not really if I do things right).

Now that I got a solid foundation laid out, including Business Logic, Data Access Layer, Database, REST webservice, etc I'm going through and trying to work in some error handling, but I'm not sure what the best approach to this is.

I was told that try-catch blocks can be performance hits (which is a big deal in this case), is
this true ? Should I use them sparingly, or just slap em wherever an exception could be thrown (I kinda would like to use them around all my SQLite API calls, since I don't know what the heck they're doing half the time).

Are using event-callbacks a bad thing for error handling ? I was advised to use these whenever possible, as opposed to try-catch, for performance reasons, but I don't want to break any design principles and paradigms and end up with sloppy-gauh-loppy code all over the place.

The third option, which has the lest amount of overhead, but is infinitly irritating to deal with, are status-fields and return values.

So what do you guys think ? I guess I'm looking for just some general direction, and maybe some suggestions on where and when to use each, and any other techniques I most likely left out. Please let me know if more details are needed, as I'd be glad to give em.

Thank you for taking some time out for this!

Answer 1

I think what made your program ugly is doing exception handling everwhere, in spite the fact that we have good exception handling patterns in place.

These kind of functionalities which will happen all over you code base is called Cross Cutting Concerns like logging, security, auditing, exception handling and ....

You can find good patterns here http://msdn.microsoft.com/en-us/library/ee658105.aspx#ExceptionManagement.

Worth to mention that i would not recommend using EntLib as recommended in Microsoft docs.

If you look for Aspect Oriented Programming(AOP), you will find good resources. And the final hint is that implementations will use a Dependency Injection/IoC Frameworks to address these concerns.

Answer 2

I kinda would like to use them around all my SQLite API calls, since I don't know what the heck they're doing half the time.

If you're saying you are using a library for interfacing with SQLite, chances are this library APIs are already throwing exceptions on certain error cases. Of course, when this is the case, you should use try/catch around these calls and handle these erroneous situations.

This is always the case when you haven't written that code yourself, when you're using someone else's library.

How you handle these errors is your decision.

My advice:

• I'm against callbacks/events for most cases. These should mostly be used when the API that results in an error is asynchronous and the program flow is already not self-evident because of that.
• Throwing exceptions is indeed slower than status-codes/return-values, but it can safely be used on any mobile platform today in any situation where the app is not time-critical. Mobile games use exception-throwing and they are time critical (kind of).
• Throwing exceptions provides for better code readability - in my opinion, it's a subjective thing - and is a nice way of jumping out of the current context in case of an error.

Answer 3

Sometimes theory doesn't line up with a particular implementation, but I imagine Mono's had these concepts in place for a while now.

A proper runtime always favors performance in the exception-free case. Ideally, in the case no exception is thrown, a try/catch block should perform just as if the contents of the try block executed on their own, and a try/finally block should execute as though the contents of the try and finally blocks were executed in order. When using a CIL bytecode interpreter, it's generally not possible to perform these operations with no overhead like I mention here. However, a decent JIT or AOT compiler (like you get with Mono) does in fact produce code that runs as fast in the exception-free case as it would if the try/catch/finally constructs were omitted.¹

If you instead choose a strategy of error codes, your application will end up executing portions of your error handling code even when no error occurs (passing an extra parameter to methods, computing and testing return codes, etc.). Your goal is therefore to restrict the use of exception handling to truly exceptional cases. This strategy leads to a robust application (proper error handling) without performance degradation for the performance-critical success cases.

¹ This is not 100% accurate in the case of a try/finally block embedded in the body of a numerical computation loop, but the chance of it having an observable performance impact when properly used for handling exceptional cases is virtually nil at this point. Specifically, a try/finally block JIT compiled for X86 will include code which resembles a push/pop/jmp (local branch) instructions as compared to the same method without the try/finally block. This is less overhead than a call to a method defined as: public static void Foo() {}