https://kotlinlang.org logo
#http4k
Title
# http4k
r

Ray Eldath

01/27/2020, 5:25 AM
ah, kinda disappointing... I now use
jacksonObjectMapper().writeValueAsString(e)
to manually convert the object, and it works fine now. i feel somewhat strange about the origin behavior. use
writeValueAsString
will format the stacktrace into a well-organized json but
.with(error of e)
will output the stacktrace solely which will crash the json parser. why
with
is designed to work in this way...? 😕
d

dave

01/27/2020, 6:33 AM
It's definitely not designed to crash and if it is then please raise an issue so we can take a look. 🙃
As far as we were concerned it should do something workable. @Ray Eldath what type of exception is it throwing?
Just had a look and the marshaller handles exceptions by calling Throwable::asString (you can override that behaviour as I mentioned above).so maybe there's something about this one that's it doesn't like...
Also - are you using Jackson?
r

Ray Eldath

01/27/2020, 6:48 AM
yeah. the problem is Jackson wrapper I think. use
Jackson.asjsonString
or
... of object
will leads to the solely string reply, constituted of the stacktrace string containing lots of
\r\n
with Content-Type
application-json
, but it's not a json object. Use
jacksonObjectMapper().writeValueAsString(object)
from package
com.fasterxml.jackson.module.kotlin
to convert manually will works fine, output the well-organized data.
emm should this be proposed as an issue...?
d

dave

01/27/2020, 6:51 AM
Yes please. We’ll fix it today but it’s good for tracking behaviour changes 🙃
r

Ray Eldath

01/27/2020, 7:08 AM
now at https://github.com/http4k/http4k/issues/361. really appreciating your patience. 😉
@dave okay, seems the problem is in
AutoMappingConfiguration
... it's specify
text(throwable())
explicitly, remove this line will make
Exception
serialized normally. should this be proposed as a pr...? i think we should provide some options for user to easily turn on/off the normal serialization of Throwable. this may derived from the assumption that all exception is child-field, so encoded them as text will produce more concise json string. but when they're not, it will cause problem. as described in #361. 🐱
d

dave

01/28/2020, 11:45 AM
yes - this is what I'd reasoned about #361 - we do need a way to represent exceptions in a standard cross-library (GSON, Jackson ... ) way.Which means that the writeValueAsString is probably not going to happen.
TBH - projects should do their own error handling - I wouldn't expect a client to attempt to deserialise (or make sense of) an exception in a 5XX response code
especially when the content type hasn't been set - hence my suggestion of the simple wrapper. You could easily put this into a custom lens to be used in the "CatchAll"-type filter
r

Ray Eldath

01/28/2020, 11:57 AM
well, my case is that, of course, use a simple wrapper which not extends
Exception
to indicate my custom diagnose message is technically absolutely no problem. but the code is kinda crazy - you have to write something like
req -> run { return@run Response(...) }
to throw the simple exception wrapper to the client. so i build a exception-based solution, enable me to use
throw
directly. well, after all, i think there should have - if not have currently - some guidelines about these exception behavior.
4 Views