ah kinda disappointing I now use `jacksonObjectMapper writeV

Question

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 confused

dave · Answer

It s definitely not designed to crash and if it is then please raise an issue so we can take a look upside down face

dave · Answer

As far as we were concerned it should do something workable < Ray Eldath> what type of exception is it throwing

dave · Answer

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 · Answer

Also are you using Jackson

Ray Eldath · Answer

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 · Answer

emm should this be proposed as an issue

dave · Answer

Yes please We ll fix it today but it s good for tracking behaviour changes upside down face

Ray Eldath · Answer

now at <https github com http4k http4k issues 361> really appreciating your patience wink

Ray Eldath · Answer

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

dave · Answer

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 · Answer

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 · Answer

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 · Answer

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