复杂异常处理委托独立类是否合规？组合继承下的实践疑问

Great question! Let's start with the core answer first: your proposed approach is not a bad practice—in fact, it aligns perfectly with the "composition over inheritance" principle you’re already following, and it’s a clean way to decouple exception handling logic from your base class.

为什么这个方案是合理的？ #

By extracting the exception handling into a separate interface and injecting it into the base class, you’re:

• Following the Open/Closed Principle: You can add new exception handling behaviors without modifying the base class itself.
• Avoiding the pitfalls of inheritance: No need to create bloated intermediate base classes that complicate your class hierarchy and create tight coupling.
• Enabling reusability: The same exception handler implementation can be shared across multiple subclasses, or you can create custom implementations for specific use cases.

可能存在的潜在弊端（以及如何规避） #

While the approach is solid, there are a few edge cases to watch out for:

1. Exception handling priority confusion #

Your original base class has a specific catch order (HttpClientErrorException → HttpServerErrorException → etc.). If your handler interface’s handleException method doesn’t clearly signal whether it’s handled the exception, you might end up with conflicting logic (e.g., both the handler and the base class’s default logic run for the same exception).

Fix: Modify the interface to return a boolean indicating whether the exception was processed:

public interface ExceptionHandler {
    boolean handleException(Exception ex);
}

Then update your base class logic to respect this signal:

try {
    doSomething();
} catch (Exception ex) {
    // Let the injected handler try to handle the exception first
    if (!exceptionHandler.handleException(ex)) {
        // Fall back to base class's default logic if handler didn't process it
        if (ex instanceof HttpClientErrorException) {
            // Base class's complicated logic
        } else if (ex instanceof HttpServerErrorException) {
            // Base class's complicated logic
        } else if (ex instanceof RestClientException) {
            // Base class's complicated logic
        } else {
            throw ex;
        }
    }
}

This way, subclasses with custom handlers can catch their specific HttpClientErrorException variants, return true, and skip the base class’s default logic for those cases.

2. Overly broad handler interface #

If your handleException method ends up handling every possible exception type, it could become a "god class" that violates the Single Responsibility Principle over time.

Fix: If your use case grows, split the interface into more focused ones (e.g., HttpClientErrorHandler, HttpServerErrorHandler) and have the base class depend on the relevant ones. For your current scenario, though, a single interface is perfectly fine.

3. Dependency management overhead #

If you’re not using a dependency injection framework (like Spring), manually passing the handler instance to each subclass can add boilerplate code.

Fix: Use a factory pattern to create and provide the appropriate handler instances for each subclass. This centralizes the handler creation logic and reduces repetition.

优选方案（优化后的组合式实现） #

Your original idea is already strong, but here’s a refined version that addresses the above concerns:

1. Define a signal-aware exception handler interface:

public interface ExceptionHandler {
    /**
     * Handles the exception if applicable.
     * @return true if the exception was handled; false to fall back to base class logic
     */
    boolean handleException(Exception ex);
}

2. Implement a base handler for default logic:

public class DefaultExceptionHandler implements ExceptionHandler {
    @Override
    public boolean handleException(Exception ex) {
        if (ex instanceof HttpClientErrorException) {
            // Base class's original complicated logic
            return true;
        } else if (ex instanceof HttpServerErrorException) {
            // Base class's original complicated logic
            return true;
        } else if (ex instanceof RestClientException) {
            // Base class's original complicated logic
            return true;
        }
        // Let the base class rethrow unhandled exceptions
        return false;
    }
}

3. Create a custom handler for subclasses that need special logic:

public class CustomHttpClientErrorHandler implements ExceptionHandler {
    private final ExceptionHandler defaultHandler;

    // Compose with the default handler to reuse common logic
    public CustomHttpClientErrorHandler(ExceptionHandler defaultHandler) {
        this.defaultHandler = defaultHandler;
    }

    @Override
    public boolean handleException(Exception ex) {
        if (ex instanceof HttpClientErrorException specificEx) {
            // Check if this is the specific variant we need to handle first
            if (specificEx.getStatusCode() == HttpStatus.CONFLICT) {
                // Special custom logic for CONFLICT errors
                return true;
            }
        }
        // Fall back to default logic for other exceptions
        return defaultHandler.handleException(ex);
    }
}

4. Inject the appropriate handler into your base class:
   Your base class can accept an ExceptionHandler via constructor injection, defaulting to the DefaultExceptionHandler if none is provided:

public abstract class BaseService {
    private final ExceptionHandler exceptionHandler;

    protected BaseService() {
        this(new DefaultExceptionHandler());
    }

    protected BaseService(ExceptionHandler exceptionHandler) {
        this.exceptionHandler = exceptionHandler;
    }

    public void doWork() {
        try {
            doSomething();
        } catch (Exception ex) {
            if (!exceptionHandler.handleException(ex)) {
                throw ex;
            }
        }
    }

    protected abstract void doSomething();
}

Subclasses that need custom behavior can inject the CustomHttpClientErrorHandler:

public class ConflictAwareService extends BaseService {
    public ConflictAwareService() {
        super(new CustomHttpClientErrorHandler(new DefaultExceptionHandler()));
    }

    @Override
    protected void doSomething() {
        // Subclass-specific logic
    }
}

总结 #

Your initial approach is a great example of applying composition over inheritance to solve a common inheritance pain point. With a few small tweaks to handle priority signaling and compose default logic, it becomes a robust, maintainable solution that avoids the pitfalls of adding intermediate base classes.

内容的提问来源于stack exchange，提问作者b15