[
https://issues.apache.org/jira/browse/SVN-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14934659#comment-14934659
]
Branko Čibej commented on SVN-4570:
-----------------------------------
The JavaHL ClientException in 1.9 contains the complete stack of error
messages, including trace/location entries.
Other than that, you can't safely wrap an {{svn_error_t*}} in Java/JNI objects,
because unlike C# or C++, Java does not have destructors so there's no way to
guarantee error cleanup.
> Add sane error information to JavaHL
> ------------------------------------
>
> Key: SVN-4570
> URL: https://issues.apache.org/jira/browse/SVN-4570
> Project: Subversion
> Issue Type: Improvement
> Components: bindings_javahl
> Affects Versions: 1.9.x
> Reporter: Bert Huijben
> Fix For: 1.10-consider
>
>
> {noformat:nopanel=true}
> 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.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
