When should we create our own Java exception classes? [closed]

From a good design/practice point of view, when should we create and use custom Java exception classes instead of the ones already predefined in Java?

In some applications I see almost custom exception classes created, they make an effort to always use native Java exceptions. On the other hand, there are some applications that define custom exceptions for (almost) everything.

From Best Practices for Exception Handling:

Try not to create new custom exceptions if they do not have useful information for client code.

What is wrong with the following code?

public class DuplicateUsernameException extends Exception {}

It is not giving any useful information to the client code, other than an indicative exception name. Do not forget that Java Exception classes are like other classes, wherein you can add methods that you think the client code will invoke to get more information.

We could add useful methods to DuplicateUsernameException, such as:

public class DuplicateUsernameException
    extends Exception {
    public DuplicateUsernameException 
        (String username){....}
    public String requestedUsername(){...}
    public String[] availableNames(){...}
}

The new version provides two useful methods: requestedUsername(), which returns the requested name, and availableNames(), which returns an array of available usernames similar to the one requested. The client could use these methods to inform that the requested username is not available and that other usernames are available. But if you are not going to add extra information, then just throw a standard exception:

throw new IllegalArgumentException("Username already taken");

from a good design/practice point of view, when should we create and use custom java exception classes instead of the ones already predefined in java?

When the existing exception names don't cover your need.

Another design concern is to extend the "good" exception class; for instance, if you raise an exception related to I/O, you should ideally inherit IOException; if the exception indicates a programmer error, you should inherit RuntimeException (ie, make your exception unchecked).

Raising custom exceptions also allows you to treat exceptions in a more precise manner; for instance, if you have defined FooException inheriting IOException, then you can have a special treatment for it:

try { ... }
catch (FooException e) { ... } // Catch it _before_ IOException!
catch (IOException e) { ... }

Also, exceptions are classes like any other, so you can add custom methods etc; for instance, Jackson defines JsonProcessingException which inherits IOException. If you catch it, you can obtain location information of the parse error using .getLocation().

certainly when you expect to be able to programmatically handle an exception - ie it's easy to create separate catch statements for different exception types, ie:

try{    
  buyWidgets();
}
catch(AuthenticationException ex)
{
  promptForLogin();
}
catch(InsufficientFundsException ex)
{
  promptToRefillAccount();
}
//let other types of exceptions to propagate up the call stack

On whether the above constitutes inappropriate use of exception for flow control

While exceptions are more CPU-expensive than if-else statements (mainly due to cost of constructing a stack trace), cost is relative and should be assessed in the context of particular use case. Not every piece of code needs to be web-scale fast and some people find reading and testing conditionals more cumbersome. For example pretty much all transaction managers implement commit-rollback-retry idioms using exceptions. (Try writing a transaction retry aspect without catching an exception)

Separately, one should adhere to separation of concerns principle: not every piece of code needs to deal with every possible condition. Whether not being logged in while buying widgets is an exceptional case really depends on the app and particular place in the app code base. For example, you could have a Service with operations for logged-in users. It makes no sense for methods in that service to deal with authentication - instead these methods would expect code earlier in the call chain to ensure user is authenticated, and thus simply throw exceptions if that is not so. Thus, for those methods being not logged in IS an exceptional case.

When should we create our own Java exception classes? [closed]

Related

Recent Posts