If a context has a coercion in its route parameters, and a request comes in that matches the context route prefix but fails the coercion, a NullPointerException is thrown (instead of the match failing/404ing).
The stacktrace shows it eventually blows up in make-context, in the call ((make-handler request) request):
java.lang.NullPointerException: null
at compojure.core$make_context$handler__4077.invoke (core.clj:285)
compojure.core$make_context$fn__4079.invoke (core.clj:293)
AFAICT the underlying cause is in the context macro that supplies the make-handler function. In its implementation it uses let-request, which handles bindings and coercion for the context parameters. Problem is that it will return nil if a coercion fails. Because make-context assumes it will always get a valid handler function from make-handler, it ends up calling (nil request).
One way to fix this is adding nil checks in make-contexthere. If that seems like the right approach I'd be happy to make a PR.
Thanks for spotting and investigating this. A nil check does seem the right approach here. A fix and a test to catch regressions would be very appreciated.
If a
context
has a coercion in its route parameters, and a request comes in that matches the context route prefix but fails the coercion, a NullPointerException is thrown (instead of the match failing/404ing).I reproduced this in a failing testcase:
The stacktrace shows it eventually blows up in
make-context
, in the call((make-handler request) request)
:AFAICT the underlying cause is in the
context
macro that supplies themake-handler
function. In its implementation it useslet-request
, which handles bindings and coercion for the context parameters. Problem is that it will returnnil
if a coercion fails. Becausemake-context
assumes it will always get a valid handler function frommake-handler
, it ends up calling(nil request)
.One way to fix this is adding nil checks in
make-context
here. If that seems like the right approach I'd be happy to make a PR.