Consistent exception hierarchy about java-u2flib-server

[emlun]

Thanks for the suggestion! That sounds reasonable, we can probably make that happen.

[emlun]

Looking at this again, I feel like there might be little point in introducing a common ancestor exception since the exceptions are used to signal mostly separate failure conditions:

• U2fBadConfigurationException means there's something wrong in the server configuration.
• U2fBadInputException means the client's response is malformed.
• NoEligibleDevicesException means the state of the client's account does not permit initiating an authentication operation, because no devices are registered.
• DeviceCompromisedException and InvalidDeviceCounterException mean the signature counter returned from the client is or has been invalid.

Can you share one or a few specific examples of ugly code caused by the current exception (non-)hierarchy? That would help decide how we want to go about this.

[jasonab]

Sure, let's look at these from my implementor's perspective:

• U2fBadConfigurationException is absolutely a runtime exception, and there's no reason for any client code to catch it.
• U2fBadInputException is a runtime exception from you, but it's a checked exception to me. I'm sending you user input that could be anything, and it could fail for any reason. I understand that this is supposed to be coming from the key, but I can't guarantee that, so I have to handle this exception to avoid a 500.
• NoEligibleDevicesException is properly a checked exception that I have to handle.
• DeviceCompromisedException is properly a checked exception.

For me, any of the final 3 could be thrown during an authentication flow, and if any of them are thrown, it means authentication failed. I agree that I might need to message them differently, but with the separate types, I have to have multiple catch blocks to differentiate the cause of the error. What would be easier for me is to be able to catch a single "u2f process failed" type exception, with an embedded error code that explains why.

Right now, I have to catch U2fBadInputException and DeviceCompromised exception separately in the same flow, but react the same way.

[emlun]

Ah yes, I see. I guess my dabbling in Scala had me still thinking in expression-oriented terms rather than Java's statement-oriented paradigm.

[emlun]

This is now released in version 0.19.0. Please have a look, and let us know if you have any more suggestions for improvements. Thanks!