Introduction

In Spring Boot, stack traces are logged because application code, framework code, or the logging statement itself chooses to include the exception object. If you want to prevent stack trace logging for a custom exception, the first step is to separate two concerns: how the exception is handled for the client and how, or whether, it is logged on the server.

Do Not Log the Exception Object If You Only Want the Message

The most direct reason stack traces appear in logs is that code logs the exception object itself.

logger.error("Business rule failed", ex);

That form tells the logging framework to print the full stack trace. If you want only a concise message, log only the message you need.

logger.warn("Business rule failed: {}", ex.getMessage());

This is often enough. The exception can still be thrown and handled normally, but the log output remains short.

Handle the Exception Explicitly in @ControllerAdvice

If the exception reaches Spring MVC without custom handling, framework logging and default error rendering may produce more noise than you want. A global exception handler gives you control over both the HTTP response and the logging behavior.

1import org.springframework.http.HttpStatus;
2import org.springframework.http.ResponseEntity;
3import org.springframework.web.bind.annotation.ControllerAdvice;
4import org.springframework.web.bind.annotation.ExceptionHandler;
5
6@ControllerAdvice
7public class GlobalExceptionHandler {
8
9    @ExceptionHandler(BusinessException.class)
10    public ResponseEntity<String> handleBusinessException(BusinessException ex) {
11        return ResponseEntity
12            .status(HttpStatus.BAD_REQUEST)
13            .body(ex.getMessage());
14    }
15}

This prevents the exception from bubbling into generic default handling paths. If you do want logging here, log it intentionally and at the level you choose.

If You Really Do Not Need a Stack Trace, Disable Its Creation

Sometimes the goal is not only cleaner logs but also avoiding stack-trace creation for expected business exceptions. In that case, the exception class itself can suppress stack-trace population.

1public class BusinessException extends RuntimeException {
2
3    public BusinessException(String message) {
4        super(message, null, false, false);
5    }
6}

This constructor disables suppression and stack-trace writing. That means even if the exception is printed, the usual captured stack trace is not there.

Use this only for exceptions that are expected control-flow or business-rule signals. It is a bad idea for unexpected failures where stack traces are useful for diagnosis.

Another option is overriding fillInStackTrace():

1public class BusinessException extends RuntimeException {
2
3    public BusinessException(String message) {
4        super(message);
5    }
6
7    @Override
8    public synchronized Throwable fillInStackTrace() {
9        return this;
10    }
11}

That produces a similar effect, though the constructor-based approach is usually clearer in modern Java.

Choose the Right Logging Policy

A good rule is:

• expected business exceptions: concise logging or no logging,
• unexpected technical failures: full stack traces.

If every validation failure produces a full stack trace in production, the logs quickly become noisy and less useful. On the other hand, if you suppress stack traces for infrastructure problems, debugging gets much harder.

The real goal is not "never log stack traces." It is "log them only when they add value."

Common Pitfalls

• Logging the exception object and then being surprised that the full stack trace appears.
• Disabling stack traces for exceptions that actually represent unexpected bugs or infrastructure failures.
• Letting the exception reach default framework handling when a @ControllerAdvice handler should own the response.
• Suppressing stack traces globally instead of only for specific expected exception types.
• Confusing exception handling for the HTTP client with logging policy for operators.

Summary

• Stack traces appear because code or framework handling chooses to log the exception object.
• If you want concise logs, log the message instead of the exception object.
• Use @ControllerAdvice to control how custom exceptions are turned into HTTP responses.
• If the exception is an expected business signal, you can suppress stack-trace creation in the exception class itself.
• Keep full stack traces for unexpected failures, and suppress them only where the exception is intentionally non-diagnostic.