Error Handling – Best Practices for External Libraries in .NET

error handlinglibrariesnet

My development environment specifically is .NET and I'm writing a DLL to be compiled and referenced in other .NET programs we'll be writing going forward.

My question is: In that DLL, what is the best practice for error handling? If you have a function doSomething(value) and it fails, do you throw an exception? Or do you return a boolean indicating success/failure and have an instance variable that you check for the error message?

Best Answer

In old times, before the invention of exceptions, the most painful thing about coding was to stop your program from blindly continuing after some API call failed. You had to check every single function-call result for being NULL, -1 or whatever the designer chose as his signal of failure, and then to return from your function with your failure-signalling value. Things like this (e.g. in C):

FILE *fp = fopen(...);
if (fp == NULL) {
    return -1;
}

One productive line of code, three ugly, boilerplate ones.

When using exceptions, this comes for free. So, wherever technically possible, use exceptions to signal failures (but not everything is a failure, e.g. when searching for a substring in a string, not finding it shouldn't throw as that's normal). Without exceptions, you're forcing your colleagues into this ugly coding style.

And put information about the failure into the exception object, if it isn't automatically included, e.g. the file name when trying to open a file, so the sysadmin reading the log knows where to search for the problem.

When consuming REST services, I'd recommend to wrap failure codes in exceptions if your REST library doesn't already do that.

Related Solutions

Exception Handling – Best Practices for Checked vs Unchecked vs No Exception

In the early days of C++ we discovered that without some sort of generic programming, strongly typed languages were extremely unwieldy. We also discovered that checked exceptions and generic programming didn't work well together, and checked exceptions were essentially abandoned.

Multiset return types are great, but no replacement for exceptions. Without exceptions the code is full of error-checking noise.

The other problem with checked exceptions is that a change in the exceptions thrown by a low-level function forces a cascade of changes in all the callers, and their callers, and so on. The only way to prevent this is for each level of code to catch any exceptions thrown by lower levels and wrap them in a new exception. Again, you end up with very noisy code.

Error Handling Strategies in Multithreaded Environments – Architecture and Concurrency

My two cents.

First, most async models I've seen in libraries tend to make me frustrated. Everybody seems to have their own slightly different brand of async, and many of those interfaces are not good. As such, I tend to like libraries that keep everything synchronous. Note that callbacks can still be good. But keep all the logic on one thread; the application programmer often wants to think about threading apart from the task the library is trying to perform.

Second, a small library devoted to asynchronous code can be a very good thing - as long as that is its sole focus. A pattern that I've seen and liked in C# is to chain together actions on different threads, but write it in almost a single threaded manner with a fluent interface. (The new keyword await is somewhat along the same lines.) One common place where this comes up is in dispatches onto the UI thread. Then provide a way to handle exceptions at the end, almost like a catch block. So for example maybe something like this:

...
int expensiveResult=-1;
YourThreadLibrary
  .Background(()=>expensiveResult=DoLongRunningTaskToCreate())
  .UI(()=>UpdateUI(expensiveResult))
  .Exception(ex=>LogIt(ex));

Exceptions are the way to go in C# and you have GC, so your situation may be different. But the pattern may still make some sense.

I know this might seem too simplistic but these are the tools that I've seen be general enough to work across many problems. The nice thing is that a fluent interface like this is definitely open to extension if written properly so you can add your .ParallelFailOnAny(params Action[]) etc.

Best Answer

Related Solutions

Exception Handling – Best Practices for Checked vs Unchecked vs No Exception

Error Handling Strategies in Multithreaded Environments – Architecture and Concurrency

Related Topic