Using callbacks instead of throwing exceptions?

Question

Idea

I am thinking of using callbacks instead of throwing exceptions in C# / .NET.

Pros and Cons

The advantages are

• no hidden goto like control flow of unchecked exceptions
• much cleaner code, especially if more than one exception is involved
• thrown exceptions are documented in the method signature and the caller is forced to think about handling exceptions but can easily pass an application-wide exception handler, an "UnhandledExceptionHandler", or null to them. So they are kind of like "soft" checked exceptions but more maintainable because exceptions can thrown afterwards by overloading the method or exceptions can be removed by no longer calling "handle" on the exception handler).
• works also well for asynchronous calls
• an exception handler can handle several exceptions that are thrown at different places
• makes explicit which exceptions should be handled. Throwing exceptions the ordinary way could still be used for exceptions you don't want to be handled like "NotImplementedException".

The disadvantages are

• not idiomatic to C# and .NET
• throwing method has to interrupt the control flow by immediately returning a return value. This is difficult if the return type is a value type.
• ? (see question below)

Question

I am probably missing a few critical disadvantages, because I am wondering why this is not used. What disadvantages have I missed?

Example:

Instead of

void ThrowingMethod() {
    throw new Exception();
}

and

void CatchingMethod() {
    try {
         ThrowingMethod();
    } catch(Exception e) {
         //handle exception
    }
}

I would do

void ThrowingMethod(ExceptionHandler exceptionHandler) {
    exceptionHandler.handle(new Exception());
}

void CatchingMethod() {
     ThrowingMethod(exception => */ handle exception */ );
}

with

delegate void ExceptionHandler(Exception exception);

defined somewhere and "handle(...)" being an extension method that checks for null, retrieves the stack traces and possibly throws an "UnhandledException" if there is no exception handler at all when the exception is thrown.

---

Example of throwing an exception in a method that did not throw an exception before

void UsedToNotThrowButNowThrowing() {
   UsedToNotThrowButNowThrowing(null);
}

//overloads existing method that did not throw to now throw
void UsedToNotThrowButNowThrowing(ExceptionHandler exceptionHandler) {
    //extension method "handle" throws an UnhandledException if the handler is null
    exceptionHandler.handle(exceptionHandler);
}

---

Example with methods that return values

TResult ThrowingMethod(ExceptionHandler<TResult> exceptionHandler) {
        //code before exception
        return exceptionHandler.handle(new Exception()); //return to interrupt execution
        //code after exception
    }

TResult CatchingMethod() {
     return ThrowingMethod(exception => */ handle exception and return value */ );
}

with

delegate TResult ExceptionHandler<TResult>(Exception exception);

Answer 1

For one thing, you'll have the overhead of needing these handlers passed to pretty much every method in your application. That's a very heavyweight dependency and a do-or-die decision to take prior to building the app.

Secondly, there's the issue of handling system-thrown exceptions and other exceptions from third-party assemblies.

Thirdly, an exception is meant to halt the execution of the program at the point it is thrown, since it really is "an exception" and not just an error that can be handled, allowing execution to continue.

Answer 2

Scalability.

As @mungflesh correctly points out you have to pass these handlers around. My first concern wouldn't be the overhead but scalability: It influences the method signatures. It would probably lead to the same scalability issue as we have in Java with checked exceptions (I don't know about C#, I only do C++ and some Java).

Imagine a call stack with a depth of 50 calls (there is nothing extreme about it, IMO). One day a change comes up and one of the callees deep down the chain that did not throw becomes a method that can now throw an exception. If it is an unchecked exception you only have to change the code at the top level to deal with the new error. If it is a checked exception or you apply your idea, you have to change ALL the involved method signatures through the call chain. Don't forget that signature changes propagate: You change the signature of those methods, you have to change your code everywhere else where those methods are called, possibly generating more signature changes. In short, scales poorly. :(

---

Here is some pseudo-code showing how I mean it. With unchecked exceptions you handle a change in the callstack of depth 50 the following way:

f1() {
  try {    // <-- This try-catch block is the only change you have to make
    f2();  
  }
  catch(...) {
    // do something with the error
  }
}

f2() { // None of the f2(), f3(), ..., f49() has to be changed
  f3();
}

...

f49() {
  f50();
}

f50() {
  throw SomeNewException; // it was not here before
}

Dealing with the same change with your approach:

f1() {
  ExceptionHandler h;
  f2(h);
}

f2(ExceptionHandler h) { // Signature change
  f3(h); // Calling site change
}

...

f49(ExceptionHandler h) { // Signature change
  f50(h); // Calling site change
}

f50(ExceptionHandler h) {
  h.SomeNewException(); // it was not here before
}

All of the methods involved (f2...f49) now have a new signature AND the calling sites have to be updated as well (e.g. f2() becomes f2(h), etc). Note that f2...f49 shouldn't even know about this change, yet, both their signature and calling sites have to be changed.

---

To put it in another way: all the intermediate calls now have to deal with the error handlers even though it is a detail they should not even know about. With unchecked exceptions, these details can be hidden.

---

Unchecked exceptions are indeed "hidden goto like control flow" but at least they scale well. No doubt, can lead to an unmaintainable mess quickly...

+1 though, an interesting idea.

Answer 3

If I get it right, if there are two possible exceptions in a method, that method need to take in two different parameters. In order to simulate the checked exceptions and make the caller be informed about the possible exceptions, you have to pass different handlers for different kinds of possible exceptions. Therefore in polymorphic situations, when you are defining an interface or an abstract class, you force the possible exceptions to the unwritten code, so the concrete implementations are not allowed to generate new types of exceptions.

As an example think you are implementing the Stream class and FileStream concrete class. You have to pass in an exception handler for the file not found exception which is bad because it forces the MemoryStream to take in the file not found exception handler, or on the other hand, you are not allowed to generate the file not found exception in FileStream, because signature does not allow it.