-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need more explicit exceptions so its easier to test in application code #488
Comments
The client exposed the ResultSet's errorCode to users and expect users handle the business code according to errorCode. Can you check the errorCode type to decide whether you can try the statement? |
@Nicole00 I'm confused, the error codes are present in the code however, the exception thrown from library does not contain the code or a clarifying exception. getSessionWrapper()
This is from Basically how does this code tell the client its a |
This is a common pattern in the library code it throws a lot of plain RuntimeException with out passing the error code or a clarifying exception. Basically taking AuthFailedException and have it inherit from RuntimeException would help. Or better yet a basse ClientException with the error code and then extend it from there for something like AuthFailedFailed or CertificateException etc. |
I agree with the view on runtime exception, it should indeed throw the specific exception. What I mean above is about the errorCode returned by server, it is contained in ResultSet. Perhaps the SessionWrapper will be |
For instance
If this was a NoSpaceFoundException it would be easier to test. Frequently we'd like know if an exception is one we can retry so having ones that implement TransitentException or some ClientException is helpful.
For instance this
NoSpaceFoundException
is not retryable.The text was updated successfully, but these errors were encountered: