skip to content

A Gradle build fails with a one-line error and no cause. Which flags do you add to get a full stack trace, and what's the difference between them?

level: middleimportance: must knowfreq 60%

answer

  1. -s truncates internals
  2. -S full incl. Gradle frames
  3. orthogonal to log level
  4. combine --info --stacktrace
  5. footer suggests --scan

basics

~10 s

Re-run with --stacktrace (-s) to print the exception's stack trace, or --full-stacktrace (-S) for the complete trace including Gradle's internal frames. By default Gradle truncates the trace.

solid answer

~40 s

By default Gradle shows a terse failure with just the message and a hint to re-run with `--stacktrace`. `-s/--stacktrace` prints a truncated trace that omits noisy internal Gradle frames — usually enough to find the failing line in your build logic. `-S/--full-stacktrace` prints the complete trace including Gradle's own internals, useful when you suspect a Gradle/plugin bug rather than your script. These are orthogonal to log level: you can combine `--info --stacktrace` to get both verbose context and the exception chain. The failure footer also points you to `--scan`, which uploads a shareable build report. Reach for `-s` first; escalate to `-S` only when the truncated trace hides the real cause.

code

bash · 11 lines
bash
# Truncated trace (skip Gradle internals) — start here
./gradlew build --stacktrace

# Full trace incl. org.gradle.* frames — suspect a Gradle/plugin bug
./gradlew build --full-stacktrace

# Verbose context + exception chain together
./gradlew build --info --stacktrace

# Shareable web report with the full cause chain
./gradlew build --scan

go deeper

for a junior

Know that -s/--stacktrace prints the trace and that the default failure is just a one-liner.

for a middle

Distinguish -s (truncated) from -S (full incl. internals), and combine with --info for context.

for a senior

Explain the reaching-for order and when to escalate to --scan for non-reproducible or shareable failures.

for a principal

Set team norms: build scans wired into CI for failure triage, guidance on when full traces matter for upstream bug reports, and not pasting --debug dumps into tickets.

## The default failure experience When a build fails, Gradle by default prints a compact summary: ``` * What went wrong: Execution failed for task ':compileJava'. > ... * Try: > Run with --stacktrace option to get the stack trace. > Run with --info or --debug option to get more log output. > Run with --scan to get full insights. ``` It deliberately omits the stack trace to keep output readable. ## --stacktrace vs --full-stacktrace - **`-s` / `--stacktrace`** — prints the exception's stack trace, but **truncates internal Gradle frames** (the `org.gradle.*` plumbing). This is the trace you want 90% of the time: it surfaces where in *your* build script or plugin the failure originated. - **`-S` / `--full-stacktrace`** — prints the **complete, untruncated** trace including all Gradle internal frames. Use it when the truncated trace hides the cause, or when reporting a suspected Gradle/plugin bug upstream. These flags are independent of log level. A common combo for a stubborn failure is: ```bash ./gradlew build --info --stacktrace ``` `--info` explains what the build was doing; `--stacktrace` shows the exception chain that aborted it. ## Build scans (--scan) The failure footer also suggests `--scan`. A build scan (`./gradlew build --scan`) publishes a rich, web-hosted report — timeline, task inputs, deprecations, the full failure with cause chain — to a shareable URL. It's the most powerful diagnostic for failures you can't reproduce locally or want a teammate to inspect, and it captures far more than a console stack trace. ## Reaching-for order 1. `--stacktrace` to see the exception chain. 2. `--info` to understand surrounding build activity. 3. `--full-stacktrace` if internals are needed. 4. `--scan` to share or deep-dive.

  • When would --full-stacktrace be more appropriate than --stacktrace?
    When the truncated trace removes the frames you need — typically when you suspect the bug is inside Gradle itself or a plugin, so you need the org.gradle.* internal frames to report it upstream.
  • What does --scan give you that a console stack trace cannot?
    A shareable web URL with a structured report: build timeline, task inputs/outputs, dependency resolution, deprecations, and the full failure cause chain — ideal for non-reproducible failures or sharing with teammates.
  • Can you combine --stacktrace with --info?
    Yes — they're orthogonal. --info raises the log threshold for context; --stacktrace controls exception-trace printing. Combining them is a standard debugging move.

saying these in an interview costs you the question

  • Saying Gradle always prints a full stack trace by default — it truncates to a one-line summary.
  • Treating --stacktrace and --full-stacktrace as identical.
  • Thinking a log-level flag (--info/--debug) alone guarantees the exception trace — you need --stacktrace for the trace itself (though --debug does include it).

context

resolving links…