[ https://issues.apache.org/jira/browse/LANG-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740898#action_12740898
]
Matt Benson edited comment on LANG-497 at 8/8/09 7:37 AM:
----------------------------------------------------------
I'm guessing you typically do not create a new ContextedFooException subclass for every FooException
you may have been accustomed to programming with, so have you seen no downside to publishing
APIs that declare "throws ContextedException"? I wonder, when this is added to [lang], if
it might be appropriate to create a sandbox component (one utility class? :| ) that could
dynamically generate Contexted subclasses. You'd need another interface to support this,
though. Then you could use APIs that are still familiar to developers but still provide context.
You could also include convenience code in this utility like:
(assume our interface is Contexted)
{code:title=ContextedExceptionUtils.java|borderStyle=solid}
public static ExceptionContext getExceptionContext(Exception e) {
return e instanceof Contexted ? ((Contexted) e).getExceptionContext() : EMPTY_CONTEXT;
}
private static final ExceptionContext EMPTY_CONTEXT = new ExceptionContext() {
public ExceptionContext addLabeledValue(String label, Serializable value) {
throw new UnsupportedOperationException();
}
public Serializable getLabeledValue(String label) {
return null;
}
public Set<String> getLabelSet() {
return Collections.<String> emptySet();
}
public String getFormattedExceptionMessage(String baseMessage) {
return baseMessage;
}
};
{code}
WDYT?
was (Author: mbenson):
I'm guessing you typically do not create a new ContextedFooException subclass for every
FooException you may have been accustomed to programming with, so have you seen no downside
to publishing APIs that declare "throws ContextedException"? I wonder, when this is added
to [lang], if it might be appropriate to create a sandbox component (one utility class? :|
) that could dynamically generate Contexted subclasses. You'd need another interface to support
this, though. Then you could use APIs that are still familiar to developers but still provide
context. You could also include convenience code in this utility like:
(assume our interface is Contexted)
public static ExceptionContext getExceptionContext(Exception e) {
return e instanceof Contexted ? ((Contexted) e).getExceptionContext() : EMPTY_CONTEXT;
}
private static final ExceptionContext EMPTY_CONTEXT = new ExceptionContext() {
public ExceptionContext addLabeledValue(String label, Serializable value) {
throw new UnsupportedOperationException();
}
public Serializable getLabeledValue(String label) {
return null;
}
public Set<String> getLabelSet() {
return Collections.<String> emptySet();
}
public String getFormattedExceptionMessage(String baseMessage) {
return baseMessage;
}
};
WDYT?
> 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, DefaultExceptionContext.java, DefaultExceptionContextTest.java,
ExceptionContext.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.