Having Multiple Exception classes aren't like Redundant, especially when we are using Error Codes?

问题

I am using Spring Boot and Spring Rest in our app.

My query is: In our app, we are using Error Codes, along with creating Multiple Exception classes. So, When we already using Custom Error Codes, whats the point to create Multiple Exception classes again? I am thinking to have create only One Custom Exception class for the whole App(say AppException), should be enough to display Error Response for all kinds of Error scenarios using Error Codes.

Okay, even for logs, we can show same Exception (ie., AppException) and also display Error code in the log itself. So When any RunTimeException Occurs, by looking at the Error Codes and respective Error Messages in the logs, we will get to know whats the actual cause, right?

So, Having Multiple Exception classes aren't like Redundant, especially when we are using Error Codes?

Please have your thoughts if I am wrong.

EDIT: FYI, below is my CustomException which takes errorcode as parameter

import java.util.Arrays;

public class MyAppException extends RuntimeException {
    private final MyAppErrorCodes errorCode;
    private final Object[] errorCodeArgs;

    public MyAppException(final MyAppErrorCodes errorCode, final Throwable cause, final Object... args) {
        super(cause);
        this.errorCode = errorCode;
        this.errorCodeArgs = Arrays.copyOf(args, args.length);
    }

    public MyAppErrorCodes getErrorCode() {
        return errorCode;
    }

    public Object[] getErrorCodeArgs() {
        return errorCodeArgs.clone();
    }
}

回答1:

If you have a generic application exception, e.g.

class ApplicationException extends Exception {
  ...
  private int errorCode; // with getter and setter
}

the real meaning of the exception situation is encoded in ApplicationException.errorCode, e.g. 4839238756

That only means something to a developer I would think and perhaps relates to a very specific error condition, such as, perhaps, cannot create new resource

You could extract the meaning to a higher level and use multiple exception classes, e.g.

class ResourceException extends ApplicationException {
  ...
}

class NetworkException extends ApplicationException {
  ...
}

the problems are then classified into discrete areas of functionality within the application and can be logged to different issues log files. The specific reason can still be encoded in errorCode.

It's whether you want to process exceptions further up the chain, e.g. having separate log files for different types of exceptions such as database errors, network errors etc, rather than working out what type of exception it is from its errorCode.

A developer who needs to fix network exceptions can focus on those as only those are logged to the issues.network.log for example and each errorCode will narrow it down further but in the context of that exception type.

If you're logging to a database you could query for all NetworkExceptions rather than a range of errorCode, e.g. all errorCode between 234342 and 898987, if you're partitioning errorCode into functional areas.

回答2:

Using both could acceptable for some reason.

Using multiple exceptions is most of the time better for error handling by the system because java handle it(try-catch).

Using error codes could now be interesting for the caller side.. imagine you want to be fine grained on the error's reason. For all illegal input you'll return a 400 bad request.. but you can enrich your responses with a business error code.

Example :