failOnUnknown() should allow setting of error type

[nnchang]

What happened?

As a java service, communicating with a storage backend via conjure, I used .failOnUnknown() when writing a visitor for the response object. I dug in though and noticed this would throw an illegal-argument exception and trigger an HTTP 400 response.

What did you want to happen?

Since this would be my application complaining about an unknown type coming from an underlying service, this definitely seems like an internal server error, HTTP 500. I would like to be able to pass an ErrorType into the .failOnUnknown() method, so I can control what HTTP status it would return without an awkward try-catch structure.

[carterkozak]

If you send a request object which is missing fields (or contains additional fields the server doesn't understand) you'll receive a 400 response. I would consider this case equivalent: The client sends data that the server doesn't understand/expect, meaning the client has made a bad request.
You could provide an onUnknown function instead of using the default .failOnUnknown() if there's a niche use case for presenting a 5xx, but I would recommend against doing that by default.

[nnchang]

I'm confused; in this case, my service is the client, and is operating on the response from an upstream service. In this case, someone sent me a request, I just tried to store it, and the unknown I'm handling is when I'm looking at the response from the storage layer. If I don't know how to interpret the response from the storage layer, that's not a bad request on my client's part, it's a bug in my code or a version mismatch between my service and the storage layer.