Currently JavaHL apis only have the (potentially localized) error output to see why some operation failed.
This error output includes generic messages for error codes, where the creator of the error intended specific messages... so the resulting message is not what a user would expect and not an easy way for applications to access the problem causes.
Eventually we should try to:
- Provide an easy way to access to causes of problems.
Probably a combination of creating multiple exception types, extending the ClientException. Perhaps providing access to error codes/error classes?
- Marshal the JavaHL exceptions through Subversion, using similar magic as that in SharpSVN.
(Errors have their own pool and we can attach information to that... and pool cleanup handles the case where Subversion decides to ignore the error). This allows handling Java errors as Java errors.
- Make it easy to generate a valuable end-user message, similar to what is shown in other clients. Without the 'freely added' generic messages in unexpected places in the chain, etc.