Design Patterns – Is It Good Practice to Use Self-Defined Exceptions?

Architecturedesign-patternsexceptions

Our team has different opinions about the practice of using self-defined exception for handling the business logic.

Someone says it is good as the exception comes meaningful and readable, and the opposition thinks it is redundant to define every possible exception and catching exceptions is performance hurting.

Would you share your thoughts and experience?

Best Answer

Like many things in programming, using custom exceptions is good if done for the right reasons and in the right situations.

If a built-in exception can acurrately describe the situation at hand, use it. E.g. FileNotFoundException, TimeoutException, KeyNotFoundException, etc.

If non of the built-in exception classes describe the situation, then you should make your own. If custom exceptions were bad, the built-in classes would be sealed or final or similar. However, don't go nuts. Just like with classes, a given exception type should probably be thrown from more than one place, otherwise it is likely unnecessarily specific.

However, a better rule of the thumb for whether to have custom exceptions is to consider what the caller will do about it when the exception gets thrown. If you have three erroneous situations that are handled in three very different ways, it makes sense to have three types because then the caller can have three catch blocks accordingly. The alternative, which is to inspect the message or data to decide what to do, is more complicated and thus more prone to error.

If all three situations instead are handled identically, it may not be worth the hassle of additional types, when just using the exception message should be enough to diagnose what the situation is. I've had to deal with many situations where a function can throw a dozen different exception types, but that to me as the caller, have inconsequential differences, so laziness kicks in and I just catch {} without the exception type and feel a little guilty about it. Don't cause that to happen.

As for one of the claims you wrote:

catching exceptions is performance hurting.

While that is true, there is virtually no difference between having custom exceptions that are caught and thrown vs just using ApplicationException for everything and making decisions based on the exception message. However, the for former situation, it is considerably easier for us humans to reason about what is happening during program execution.

Related Solutions

Java Exceptions – Better Way to Define an Exception Thrown by a Method

I'm going to assume that there are situations where it is reasonable to throw exceptions.

I'm also going to assume that this is a situation where it is reasonable to use exceptions. (The fact that this is "internal" to your code does not alter this. And you cannot reasonably infer that exceptions are in appropriate based on the proposed exception name ... @Jarrod Roberson note!)

So the question is whether it is reasonable to declare a private exception class. To that I would say "Yes", assuming that there is no existing exception class that is suitable.

The only riders I would make is that if there is any chance that the exception might "leak", then:

you should declare a constructor so that the exception has a reason String, and
you should declare it as public ... so that any javadoc for the exception appears in the published API documentation.

C# – Web API : Centralize business transaction logic : Good Idea

Of course you could move this code to some class that handles this for you, for example using the business logic as an Action (https://msdn.microsoft.com/en-us/library/system.action(v=vs.110).aspx) or something like that. This could definitely be a solution for the transaction management and probably for the HTTP 500 and 200 result codes.

public class MyTransactionManager  // Think of proper names
{
    public void Execute(Action action)
    {
        try
        {
            _unitOfWork.BeginTransaction();
            action();
            _unitOfWork.Commit();
        }
        catch (Exception e)
        {
            // .. handling .. 
        }
    }
}

Calling it from the Controller:

[HttpPost]
public IActionResult CreateItem(Item item)
{
    Action action = delegate() { _myService.CreateItem(item); } ;
    _transactionManager.Execute(action);
}

you may need to check the details about calling the Action, haven't tried this).

However, you will also need some error handling for specific situations. Any call to your WebAPI can have different situations when to return which HTTP error code like the 4xx's. Those checks will always be in the Controller itself.

Don't get tempted to return StatusCodes from your business logic.

Best Answer

Related Solutions

Java Exceptions – Better Way to Define an Exception Thrown by a Method

C# – Web API : Centralize business transaction logic : Good Idea

Related Topic