It's a common pattern for Ring handlers to return nil. However, when this is the case, coercion-middleware explodes with non-informative message:
java.lang.NullPointerException
at fnhouse.middleware$response_walker$fn__5341.invoke(middleware.clj:90)
at fnhouse.middleware$eval5351$coercion_middleware__5352$fn__5356$fn__5358.invoke(middleware.clj:113)
at fnhouse.routes$eval4736$root_handler__4737$fn__4738$fnk4739__4745$fn__4746.invoke(routes.clj:131)
at fnhouse.routes$eval4736$root_handler__4737$fn__4738$fnk4739__4745.invoke(routes.clj:128)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.lang.AFunction$1.doInvoke(AFunction.java:29)
at clojure.lang.RestFn.invoke(RestFn.java:408)
...
It happens when anonymous function in response-walker gets nil for response. I don't know what would be better: to give more informative message there or to skip output coercion, assuming that there is an or somewhere upstream and other handler will be called or 404 will be raised.
Which approach is better and should I make a PR with fix?
It's a common pattern for Ring handlers to return
nil. However, when this is the case,coercion-middlewareexplodes with non-informative message:It happens when anonymous function in
response-walkergetsnilforresponse. I don't know what would be better: to give more informative message there or to skip output coercion, assuming that there is anorsomewhere upstream and other handler will be called or 404 will be raised.Which approach is better and should I make a PR with fix?