Getting safer error messages out of Dropwizard / JAX-RS

[Mahoney]

Hi,

We're using Dropwizard 4.x (under the hood, Jersey 3.x with Jackson 2.17.1) with Kotlin data classes.

When someone sends us some JSON that the jackson-module-kotlin cannot convert into a data class we would like to convert the resulting MismatchedInputException into a nice message for our users. Unfortunately the simple way to do it exposes our internal code model - the message on the exception could be:

Cannot construct instance of org.example.myapp.NewThingRequestBody (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('I put a string in not an object')

or

Instantiation of [simple type, class org.example.myapp.NewThingRequest] value failed for JSON property thing due to missing (therefore NULL) value for creator parameter thing which is a non-nullable type

or

Instantiation of [simple type, class org.example.myapp.NewThingRequestBody] value failed for JSON property name due to missing (therefore NULL) value for creator parameter name which is a non-nullable type

I'd like to turn those into an error that is as helpful as possible for the user, without revealing details of our classes. So the first would become:

JSON property .thing should be a String

and 2 would become:

JSON property .thing is required

and 3 would become:

JSON property .thing.name is required

or something like that. Unfortunately I'm struggling to differentiate between type errors and missing property errors... it looks like that information is thrown away somewhere in the construction of the exception's error message, and I would be left having to parse the error message and hope it never changes to infer the problem... has anyone solved this in a better way?

[cowtowncoder]

I can see why things are problematic due to Jackson seeing problem at somewhat lower level (specific problem wrt POJO definition and input) whereas from user (and other library/framework) perspective some of these are logically equivalent or at least similar. I don't have a good solution from Jackson side.

But couple of quick notes in case they might help.

1. Jackson 2.18 will have rewritten property discovery code. While it should not change how problems are surfaced (wrt API compatibility), it may improve handling of formerly failing cases and perhaps allow reporting information more accurately. But most importantly, due to fixes to some of handling, Kotlin module need not provide some of workarounds that were needed in 2.17 and before.
2. Most of what is needed should come from jackson-databind as Kotlin module mostly relies on databind detecting of Creator methods (constructors, factory methods) and matching of input to Creator parameters.

That is, if you haven't tried out 2.18.0-SNAPSHOT that might worth it.
(I realize that even things improve with 2.18.0, as I hope, frameworks like DropWizard need to support multiple Jackson versions -- so it might be the case that DW behavior may be Jackson-version dependant).