TemplateInputException when Thymeleaf SpringTemplateResolver cannot resolve login template

Short answer

In a Spring Boot application on Thymeleaf 3.1.x, set throwExceptionIfNotFound to false if you want a missing template to fall through to your custom error view instead of surfacing a TemplateInputException. In 3.1.x this is already the default, so the main work is verifying your view resolver chain actually handles the null result — and understanding that the flag only governs SpringTemplateResolver, not every resolver in your chain.

What the flag actually does

When throwExceptionIfNotFound is true, SpringTemplateResolver throws TemplateInputException as soon as it cannot resolve a template. When it is false, resolution returns null instead, which lets ThymeleafViewResolver (or your own error handling) treat the miss as a renderable fallback rather than a hard failure. The default changed between 3.0.x and 3.1.x, so behavior can flip silently after an upgrade — worth confirming explicitly rather than relying on the default.

# application.properties (Spring Boot 3.x / Thymeleaf 3.1.x)
spring.thymeleaf.throw-exception-if-not-found=false

If the property appears to be ignored in your setup, define the resolver bean explicitly — that is the reliable path:

@Bean
public SpringTemplateResolver templateResolver() {
    SpringTemplateResolver r = new SpringTemplateResolver();
    r.setPrefix("classpath:/templates/");
    r.setSuffix(".html");
    r.setThrowExceptionIfNotFound(false);
    return r;
}

How caching changes the timing

With spring.thymeleaf.cache=true, the outcome of the first resolution attempt for a given template name is cached. If the first request for a missing template resolves to null (because the flag is false), that null result is what gets cached: subsequent requests short-circuit to the fallback immediately, with no re-resolution and no exception. The practical consequence:

• Production (cache on): the miss is resolved once, then silently masked. Debugging is harder because logs stop showing resolution activity.
• Tests / dev (cache off): every request re-resolves, so any resolver-side failure surfaces on each request, and timing depends entirely on your resolver logic.

So the exception "timing" question has a subtle answer: with the flag off there is no exception from SpringTemplateResolver at all; caching only determines how often resolution is attempted.

The DatabaseTemplateResolver edge case

Yes — a custom DatabaseTemplateResolver that throws when credentials are null will propagate TemplateInputException regardless of the flag. throwExceptionIfNotFound is a convention on SpringTemplateResolver, not a contract of the ITemplateResolver interface. If your custom resolver should honor the same fallback behavior, it must explicitly return null on "not found" conditions instead of throwing. A resolver that throws on infrastructure problems (missing credentials) is arguably correct — that is a configuration error, not a missing template — but be aware it bypasses your error view entirely.

Verification

1. Request a non-existent template name with the flag off: confirm your error view renders and no TemplateInputException reaches the error handler.
2. Enable the cache, request the missing template twice, and confirm the second request does not re-invoke the resolver (add logging or a counter in a test resolver).
3. Point the chain at your database resolver with null credentials and confirm the exception still propagates — proving the flag's scope.

One caveat: exact property support and default values should be checked against your specific Spring Boot / Thymeleaf versions, since this behavior shifted across releases. Verify against your dependency tree before relying on defaults.