How to replace if-else blocks in Java when working with derived types from the basic Throwable?

For example, there is a code that, depending on the subtype of the type Throwable, will fill the object with data and return it to the call point.

@Component
@Slf4j
public class GlobalErrorAttributes extends DefaultErrorAttributes {

    @Override
    public Map<String, Object> getErrorAttributes(ServerRequest request, ErrorAttributeOptions options) {
        Map<String, Object> map = new LinkedHashMap<>();
        Throwable error = super.getError(request);
        HttpStatus errorStatus;
        String messageDetail = null;

        if (error instanceof UserAlreadyExistsException) {

            Throwable cause = error.getCause();

            if (cause != null) {
                messageDetail = error.getCause().getMessage();
            }

            errorStatus = HttpStatus.NOT_ACCEPTABLE;
            log.error("error - {}, status - {}, detailMessage - {}",
                    error.getMessage(),
                    errorStatus,
                    messageDetail);
        }

        if (error instanceof UserNotFoundException ||
                error instanceof ResponseStatusException || error instanceof PasswordInHashNotFoundException) {

            Throwable cause = error.getCause();

            if (cause != null) {
                messageDetail = error.getCause().getMessage();
            }

            errorStatus = HttpStatus.NOT_FOUND;
            log.error("error - {}, status - {}, detailMessage - {}",
                    error.getMessage(),
                    errorStatus,
                    messageDetail);
        }else if (error instanceof BadSqlGrammarException) {

            Throwable cause = error.getCause();

            if (cause != null) {
                messageDetail = error.getCause().getMessage();
            }

            errorStatus = HttpStatus.NOT_ACCEPTABLE;
            log.error("BadSqlGrammar error: error - {}, status - {}, detailMessage - {}",
                    error.getMessage(),
                    errorStatus,
                    messageDetail);
        } else {

            Throwable cause = error.getCause();

            if (cause != null) {
                messageDetail = error.getCause().getMessage();
            }

            errorStatus = HttpStatus.INTERNAL_SERVER_ERROR;
            log.error("Not defined error: error - {}, status - {}, detailMessage - {}",
                    error.getMessage(),
                    errorStatus,
                    messageDetail);
        }
        map.put("status", errorStatus.value());
        map.put("message", error.getMessage());
        map.put("detailMessage", messageDetail);
        return map;
    }
}

A made a model like this

        Map<Throwable, Supplier<String>> handler = new LinkedHashMap<>();

        PasswordInHashException passwordInHashException =
                new PasswordInHashException("passwordInHashException", new Throwable());

        PasswordInHashNotFoundException passwordInHashNotFoundException =
                new PasswordInHashNotFoundException("passwordInHashException");


        handler.put(passwordInHashException, () -> {
            System.out.println("passwordInHashException");
            return "passwordInHashException";
        });

        handler.put(passwordInHashNotFoundException, () -> {
            System.out.println("passwordInHashNotFoundException");
            return "passwordInHashNotFoundException";
        });

However, the difficulty lies in how to force the key to be checked in Map using the instanceof operator.

Since there are a lot of Exceptions types and this method will grow, but I would like to make it so that without changing this method, expand the ability to process new Exceptions. And it is even better to use Spring's capabilities for automatic initialization of components, then it is enough to implement a new type that will be automatically added to the Map and, if necessary, depending on the exceptions that occurred, the filled object was returned and a programmed action was performed (for example, writing to the log).

 Map<String, Supplier<String>> handler = new HashMap<>();

        PasswordInHashException passwordInHashException =
                new PasswordInHashException("passwordInHashException", new Throwable());

  handler.put("PasswordInHashException", () -> {
            System.out.println("passwordInHashException");
            return "passwordInHashException";
        });

 Throwable key =  new PasswordInHashException("passwordInHashException", new Throwable());
        String simpleName = key.getClass().getSimpleName();

         handler.get(simpleName).get();

Please share your ideas.

There are a few options :

1. Polymorphism

The exceptions know how to behave here themselves

record StatusAndMessage(HttpStatus errorStatus, String message, String messageDetail) {}
interface SelfHandling {
StatusAndMessage handle()
}
@Component
@Slf4j
public class GlobalErrorAttributes extends DefaultErrorAttributes {
@Override
public Map<String, Object> getErrorAttributes(ServerRequest request, ErrorAttributeOptions options) {
Throwable error = super.getError(request);
StatusAndMessage statusAndMessage;
if (error instanceof SelfHandling selfHandling) {
statusAndMessage = selfHandling.statusAndMessage()
} else {
statusAndMessage = new StatusAndMessage(
HttpStatus.INTERNAL_SERVER_ERROR,
error.getMessage(),
error.getCause() != null ? error.getCause().getMessage() : null;
)
}
log.error("Not defined error: error - {}, status - {}, detailMessage - {}",
statusAndMessage.message(),
statusAndMessage.errorStatus(),
statusAndMessage. messageDetail());
map.put("status", statusAndMessage.errorStatus().value());
map.put("message", statusAndMessage.message());
map.put("detailMessage", statusAndMessage. messageDetail());
return map;
}
}

• Downside : This doesn't work for 3rd party exceptions. So you have to either wrap those in your own, or choose a different approach.
• Upside : this method doesn't need to change if you define new Exceptions

2. Double dispatch

• Downside : ugly (so no code example)
• Upside : You can vary behavior
  per context. If exceptions may need a different status depending on
  the request for instance.

3. Chain of Responsibility

// implementations will return Optional.empty() if they can't handle the Throwable
interface ExceptionToResponseMapper extends Function<Throwable, Optional<StatusAndMessage>> {
}
@Component
@Slf4j
public class GlobalErrorAttributes extends DefaultErrorAttributes {
private final List<ExceptionToResponseMapper> mappers;
// order of the mappers matters
public GlobalErrorAttributes(List<ExceptionToResponseMapper> mappers) {
this.mappers = List.copyOf(mappers);
}
@Override
public Map<String, Object> getErrorAttributes(ServerRequest request, ErrorAttributeOptions options) {
Throwable error = super.getError(request);
StatusAndMessage statusAndMessage = mappers.stream()
.map(mapper -> mapper.apply(error))
.flatMap(Optional::stream)
.findFirst()
.orElseGet(() -> new StatusAndMessage(
HttpStatus.INTERNAL_SERVER_ERROR,
error.getMessage(),
error.getCause() != null ? error.getCause().getMessage() : null
));
log.error("Not defined error: error - {}, status - {}, detailMessage - {}",
statusAndMessage.message(),
statusAndMessage.errorStatus(),
statusAndMessage. messageDetail());
map.put("status", statusAndMessage.errorStatus().value());
map.put("message", statusAndMessage.message());
map.put("detailMessage", statusAndMessage. messageDetail());
return map;
}
}

• Downside : easy to forget writing extra handlers when introducing a new Exception
• Upside : works easily on 3rd party exceptions