On Sun, Jun 9, 2019 at 8:43 AM 'Sven Richter' via Clojure < clojure@googlegroups.com> wrote:
> Hi Alex, > > I tracked it down to a minimal example with an explanation here: > https://gist.github.com/sveri/1aaad9b12a8ec90d243206ab3b6073e3 > > The short version is. Running a specced function in the clj repl will > produce meaningful output, while running in the web context with immutant > will print a stacktrace with the ExceptionInfo exception. > > I also tried to catch the exception and *(-> ex Throwable->map > clojure.main/ex-triage clojure.main/ex-str) *as you suggested, which > works. But like I said, I would not want to check for exceptions during > production that are only thrown during development. > The generic question here is "what happens when my web request handler throws an unexpected exception?" An exception can be thrown in either dev or prod. "spec" errors are not special in this regard. Yes, you happen to be doing some extra checking in dev, but in either case you want to properly handle exceptions. The error handling chain above will give you better output for all exceptions, not just spec. > > Do you know of a different way? Maybe a middleware would be feasible that > is only added during development? > The question of how to handle exceptions in immutant is an immutant question. If you read the docstring of immutant.web/run, it tells you how to do it for ring handlers: For ring handlers, the actual writing of the response happens after your hander returns. If an exception occurs on the write (the most common case being an IOException because the client has gone away), the default behavior is to log the exception. *If you would like to be able to handle that exception yourself, you can return a function in the ring response under :write-error-handler.* This function will be called with the exception, the request map, and the response map if an exception occurs when writing the response. Note that this handler can't actually affect the response. *If you would prefer a global handler, see immutant.web.middleware/wrap-write-error-handling*. It might be a reasonable improvement to immutant to do this better error printing by default (with the caveat that you have to be on Clojure 1.10 to do so). > What does the clj repl do to produce that output? > It catches exceptions during the read, eval, and print phases and calls (-> ex Throwable->map clojure.main/ex-triage clojure.main/ex-str) > Thank you for your time, > Sven > > Am Samstag, 8. Juni 2019 20:52:27 UTC+2 schrieb Alex Miller: >> >> >> >> On Saturday, June 8, 2019 at 1:41:59 AM UTC-5, Sven Richter wrote: >>> >>> >>> >>> Am Freitag, 7. Juni 2019 15:35:41 UTC+2 schrieb Alex Miller: >>>> >>>> How do you start the web server? >>>> >>> I use component to startup immutant web, I also tried with http-kit, but >>> that didnt make a difference. >>> >> >> What I mean is, what command do you use? Are using "lein ring server" or >> something like that? >> >> >>> >>> Who is printing the error? >>>> >>> I think thats the key point here, right now I dont know as I never >>> bothered to figure out who prints the stacktraces. >>> >> >> I don't think you're going to be able to improve this without >> understanding the answer to that question. >> >> >>> >>> >>>> There are functions available in clojure.main to replicate the message >>>> from the repl - you can call them yourself. >>>> >>>> See https://clojure.org/reference/repl_and_main#_error_printing for >>>> more on error triage and the functions like Throwable>map, >>>> clojure.main/ex-triage, and clojure.main/ex-str. This chain of functions is >>>> what the REPL uses to produce the message below >>>> >>> >>> >>> Thanks, I will try that, but that would mean I will have to catch every >>> potential ExceptionInfo error and check if its a spec error which is pretty >>> cumbersome, especially as I only want to see these outputs during >>> development (instrument is turned off in production). >>> >> >> The triage process knows how to print a good message for any error, not >> just a spec instrumentation error. There shouldn't be any conditional >> needed. >> >> >>> >>> Thanks, >>> >>> Sven >>> >>> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/RKb6XOjCK8A/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/d667e44b-397f-4a34-9c95-a0ab9adc4f54%40googlegroups.com > <https://groups.google.com/d/msgid/clojure/d667e44b-397f-4a34-9c95-a0ab9adc4f54%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAOdgdgzvtd2sGRnVShDzk42dF0h_MVj%3DMuKDf2FABmbhwaYvKQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
