Add new mapping exception type for enums and UUIDs (and maybe in future for subtypes)

[natnan]

Extension request to #32.

I'm using dropwizard and I'd like to be able to return more friendly messages to the user when they enter wrong String for enum (which I also use for subtypes) and format for UUIDs. Could we add new exception(s) for these cases? Or use InvalidFormatExcetion for all or some of them?

[natnan]

Congratulations on issue #1000 by the way :).

[cowtowncoder]

That is possible, yes, and sounds like a potentially good idea. I'll have to check what exact type to use, and try to make sure all codepaths produce the same thing. Sub-type should probably be JsonMappingException; this would also retain path information and be quite backwards-compatible.

And yes, congratulations -- you just won a FREE copy of the Jackson library! Downloadable via central Maven repository.

[natnan]

Sub-type should probably be JsonMappingException;

I'm fine with that. JsonMappingException is fine for all of them actually, as long as I can distinguish them. And that's my problem here. Subtype and enum failures construct JsonMappingException with String msg constructor. And String isn't the best way to distinguish errors.

UUID failure on the other hand, has a cause field that is NumberFormatException, so that's actually something I can work with.

If you decide which way to go, I might be able to send a PR.

[cowtowncoder]

Ah actually you are right: InvalidFormatException is existing Jackson exception type, extending JsonMappingException, so that would work better than basic JME. So that would make lots of sense. Somehow I was assuming use of JDK exception like IllegalArgumentException.

As to UUIDDeserializer, it actually looks like it should also use InvalidFormatException; I could change this as well. One potential concern is cause, which existing code might want to look at. So maybe that should be retained.

[cowtowncoder]

Edited title a bit since I think I will first tackle enum and UUID case: improvements to indicating subtype may well make sense but will probably require bit different approach, unless I misunderstood the request. Problem being not just that there are many other edge cases (wrt default type to use, or not), but also that it's more of a mismatch than invalid format problem (although there are similarities as well).

[natnan]

👍
Yeah, I agree subtype is a different case than formatting from "object" perspective. From user (i.e. REST client) and JSON perspective though, it's quite similar I'd say.

[cowtowncoder]

Improved UUIDDeserializer, EnumDeserializer the way I think they should work. Feel free to open a separate issue for subtype resolution as necessary, ideally showing case(s) where it should be changed wrt format problems, or perhaps by introducing a new sibling exception type. In fact, might make sense to have separate ones for type id resolution problems (unknown type ids) and object id resolution (unknown object id).

[natnan]

Ah, great! Thank you!. I'll create the issue now for the sake of backlog.