skip to content

What do --stacktrace (-s) and --full-stacktrace (-S) do, and how do they differ from the log-level flags?

level: middleimportance: must knowfreq 45%

answer

  1. -s = truncated, filters Gradle internals
  2. -S = full, unfiltered
  3. default failure shows message, no trace
  4. orthogonal to -q/-i/-d
  5. -d implies full stacktrace

basics

~10 s

On a build failure, -s prints a truncated stacktrace (internal Gradle frames filtered out); -S prints the full, unfiltered stacktrace. They control exception detail only — not the log verbosity level.

solid answer

~40 s

By default a Gradle failure shows the exception **message** and a hint to re-run with `--stacktrace`, but **not** the stacktrace itself. **`-s` / `--stacktrace`** turns on a *truncated* stacktrace: you get the relevant frames with most internal Gradle plumbing filtered out — usually enough to locate a failing plugin or build-script line. **`-S` / `--full-stacktrace`** prints the **complete, unfiltered** stacktrace, including all internal Gradle and Groovy/Kotlin DSL frames — noisy, but necessary when the truncation hides the real cause or you're filing a Gradle bug. These flags are **orthogonal** to the verbosity flags (`-q`/`-i`/`-d`): they only affect *exception* rendering on failure, so you can combine them freely, e.g. `gradle build -q -S`. Note `-d`/`--debug` implies full stacktraces as part of its everything-on behavior.

code

bash · 2 lines
bash
gradle build -s      # truncated stacktrace on failure (common first step)
gradle build -S      # full, unfiltered stacktrace (deep debugging / bug reports)

go deeper

for a junior

Know that -s gives a stacktrace on failure and -S gives the full one.

for a middle

Explain truncated vs full, the default no-trace behavior, and that these are orthogonal to verbosity.

for a senior

Discuss when truncation hides the root cause and that --debug implies full stacktraces.

for a principal

Recommend defaults (e.g. --stacktrace on CI) and weigh log volume vs diagnosability for the team.

## What you see by default on failure When a build fails, Gradle prints: ``` * What went wrong: Execution failed for task ':compileJava'. > <message> * Try: > Run with --stacktrace option to get the stack trace. ``` No stacktrace — just the message and a suggestion. This keeps normal failures readable. ## --stacktrace / -s : truncated Adds a stacktrace with **internal Gradle frames filtered out**. You see your build-script frames and the immediate cause, but the framework's own call stack is collapsed. This is the right first step for most failures — enough to pinpoint the offending plugin, task, or line without scrolling through framework noise. ## --full-stacktrace / -S : everything Prints the **entire** stacktrace with no filtering — all Gradle internals, DSL-runtime frames, and nested causes. Use it when: - the truncated trace hides the real root cause (the relevant frame got filtered), - you suspect a Gradle/plugin bug and need to file a report, - you're chasing a `ClassNotFound`/`NoSuchMethod` deep in machinery. ## Orthogonal to log level These flags change **how exceptions are rendered on failure**, not which log messages appear. So: ```bash gradle build -q -s # quiet output, but a truncated stacktrace on failure gradle build -i -S # info verbosity + full stacktrace ``` ## Interaction with --debug `-d`/`--debug` implies full-stacktrace behavior because DEBUG turns *everything* on. So you rarely need `-S` alongside `-d`. ## Mnemonic Lowercase `-s` = **s**maller (truncated); uppercase `-S` = the **S**uper/full one.

  • Can you combine --stacktrace with --quiet?
    Yes — stacktrace flags control exception rendering, not log level, so -q -s gives near-silent output with a truncated trace on failure.
  • If --debug is on, do you still need --full-stacktrace?
    No. DEBUG turns everything on and already implies full stacktraces.
  • Why might a truncated stacktrace be misleading?
    The filtering can remove the frame that actually carries the root cause; --full-stacktrace shows it.

saying these in an interview costs you the question

  • Claiming -s/-S change the log verbosity level — they only affect exception detail.
  • Saying Gradle prints a full stacktrace by default — by default it shows only the message and a hint.

context

resolving links…