[
https://issues.apache.org/jira/browse/LANG-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702678#action_12702678
]
Joerg Schaible commented on LANG-497:
-------------------------------------
Hi Derek,
it seems different people have the same needs :)
We did something similar in XStream with the
[ErrorWriter|http://xstream.codehaus.org/javadoc/com/thoughtworks/xstream/converters/ErrorWriter.html].
While this name is really questionnable, it is nevertheless a fine thing to
factor out the interesting methods into an interface that can be implemented by
any Exception without the need to derive from a special one. What about an
interface (e.g. ExceptionContext) with combined functionality:
{code:java}
interface ExceptionContext {
ExceptionContext addLabeledValue(String, Serializable);
Serializable getLabeledValue(String);
Iterator<String> getLabels();
}
{code}
You might then expose ContextExceptionUtils as top level class (maybe now with
a name like MemoryExceptionContext) also implementing this interface. Then you
can use it in Contexted(Runtime)Exception a simple delegate - as everybody else
can do also for other exceptions.
Opinions?
> Addition of ContextedException and ContextedRuntimeException
> ------------------------------------------------------------
>
> Key: LANG-497
> URL: https://issues.apache.org/jira/browse/LANG-497
> Project: Commons Lang
> Issue Type: New Feature
> Reporter: Derek C. Ashmore
> Fix For: 3.0
>
> Attachments: ContextedException.java, ContextedExceptionTest.java,
> ContextedRuntimeException.java, ContextedRuntimeExceptionTest.java
>
>
> This is a proposal for a feature addition.
> These additional exceptions (checked and unchecked versions) provide an
> easier and safer
> way for developers to provide context when generating checked exceptions.
> Often,
> additional information, besides what's embedded in the exception cause, is
> needed
> for developers to debug and correct a bug. Often, this additional
> information can
> reduce the time it takes to replicate and fix a bug.
> ContextedException are easier as developers don't need to be concerned
> with formatting the exception message to include additional information
> with the exception. Additional information is automatically included
> in the message and printed stack trace. This often thins out exception
> handling code.
> ContextedException is safer as the additional code needed to embed additional
> information in a normal exception tends to be tested less and is more
> vulnerable
> to errors such as null pointer exceptions.
> An unchecked version of this exception is provided by
> ContextedRuntimeException.
> To use this class write code as follows:
>
> try {
> ...
> } catch (Throwable e) {
> throw new ContextedException("Error posting account transaction", e)
> .addLabeledValue("accountNumber", accountNumber)
> .addLabeledValue("amountPosted", amountPosted)
> .addLabeledValue("previousBalance", previousBalance)
> }
> }
> The value of the context information is automatically included in the
> exception message and
> when the stack trace is printed in the log.
> My motivation for contributing is that I've previous versions of this running
> at four clients now -- I'm tiered of copying this from client to client.
> I've attached the two exceptions themselves along with working test cases.
> Every effort has been made
> to adhere to your existing style, conventions, and standards. No changes are
> needed for any
> existing files.
> I ran the site generation -- These additions pass your checkstyle reports.
> To streamline the committers time, I'll be happy to make any needed changes
> to to get this
> into 3.0.
> I know you're busy -- thanks for taking the time to at least review this
> proposal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
