[
https://issues.apache.org/jira/browse/SVN-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Zhakov updated SVN-4570:
-----------------------------
Description:
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.
was:
{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}
> 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
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
