ah, kinda disappointing... I now use `jacksonObjec...

# http4k

[Ray Eldath]

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...? 😕

[dave]

It's definitely not designed to crash and if it is then please raise an issue so we can take a look. 🙃

[dave]

As far as we were concerned it should do something workable. @Ray Eldath what type of exception is it throwing?

[dave]

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...

[dave]

Also - are you using Jackson?

[Ray Eldath]

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.

[Ray Eldath]

emm should this be proposed as an issue...?

[dave]

Yes please. We’ll fix it today but it’s good for tracking behaviour changes 🙃

[Ray Eldath]

now at https://github.com/http4k/http4k/issues/361. really appreciating your patience. 😉

[Ray Eldath]

@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. 🐱

[dave]

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.

[dave]

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

[dave]

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

[Ray Eldath]

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.