Generally Exceptions are usually thrown by parts of the code that encounter unrecoverable situation. Like famous NullReferenceException is thrown when code tries to access properties of object that is null. I’m sure you know this, don’t need to tell that 101 of programming again. My point is that exceptions are always thrown and it is down to other parts of code to catch exceptions and do something with them. Because if exceptions are not caught, the’ll bubble up to the top level and will crash your application.

I’ve never seen any methods that return exceptions. Never thought of exceptions as something that can be returned by a method. Have you?

Today I’ve spent some time doing work on bundling and minification in MVC5 project. I did open dotPeek decompiler to check how it actually works. And I came across this bit of code:

  Exception exception = this.Items.IncludePath(virtualPath, transforms);
  if (exception != null)
  {
    throw exception;
  }
  // do other stuff

I’m not posting full source code here, but it is available from MS Symbols server. That’s where dotPeek got the sources from

Note in the block above a method does something and exception is returned. It does not throw exception. Exception is thrown a level closer to user – method I’m showing you is public and I’m going to use it. Method that returns exception is internal and not accessible for consumer.

My first reaction was that this breaks Clean Code convention: method modifies state of application and does not return objects, or method returns information, but does not change anything. Basically commands and queries in CQRS: commands for writing, queries for gathering data.
Here we have a clear violation – method modifies program state and returns exception.

I went exploring deeper and looked through some other methods. The convention in this library is: private methods return exceptions. Public methods throw exceptions. This looks strange and new to me.

Remembering university course on machine code (a.k.a. Assembler, yes, I’ve done that one and loved it!) throwing an Exception involves walking execution stack which involves a lot of CPU cycles and tracing (details escape me now). This results thrown exception being expensive in terms of CPU cycles. A quick googling revealed a stack of answers and blog posts to confirm my understanding.

Given this, I presume this technique is used in the library to avoid performance penalty on throwing an exception. And the deeper the exception is thrown in the execution stack, the slower it is. Also this technique adds a lot of extra boilerplate code to methods. If you use traditional throw new Exception() then instead of this:

    Exception exception = this.IncludePath(virtualPath, (IItemTransform[]) null);
    if (exception != null)
      return exception;

you’d simply have this:

this.IncludePath(virtualPath, (IItemTransform[]) null);

Where private method would just throw an exception.

Bottom line. Unless this is used for purposes other than optimisation, don’t use this technique – it’s confusing and against conventions. And if you find your exceptions to be a bottleneck (enough to optimise it), you throw way too many exceptions and need to rethink your application. If there is other purpose to this approach, please tell me!