commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <>
Subject [jira] [Commented] (LANG-1369) Formatted and Paramaterized Exception Classes
Date Tue, 12 Jun 2018 19:25:00 GMT


Gary Gregory commented on LANG-1369:

IMO, these are not helpful or good design because they subclass Exception directly, so your
code effectively ends up with "throws Exception" all over, a bad smell usually. What you care
about is the ease of formatting a message for a specific _kind of_ exception. You must keep
is the exception already in use, like an {{IOException}} for example.

At work, I've introduced factory classes like {{IOExceptionFactory}} which contain static
methods like {{format(String, Object...)}}. This is OK for us since there are usually are
a smallish set of exceptions to throw with like {{SQLException}}, a few {{Illegal*}} exceptions,
and so on.

The generic alternative is:

public class ExceptionFactory {

    public static <T extends Throwable> T format(Class<T> clazz, String format,
Object... args)
            throws NoSuchMethodException, IllegalAccessException, InvocationTargetException,
InstantiationException {
        return ConstructorUtils.invokeExactConstructor(clazz, String.format(format, args));

But that is super lame due to the laundry list of checked exceptions, so you could do instead:

public class ExceptionFactory {

    public static <T extends Throwable> T format(Class<T> clazz, String format,
Object... args) {
        final String message = String.format(format, args);
        try {
            return ConstructorUtils.invokeExactConstructor(clazz, message);
        } catch (NoSuchMethodException | IllegalAccessException | InvocationTargetException
                | InstantiationException e) {
            throw new IllegalArgumentException(
                    String.format("Caught %s while building exception class %s for message
%s", e, clazz, message), e);
Which is not as nasty but you are still using reflection which some folks might not like,

> Formatted and Paramaterized Exception Classes
> ---------------------------------------------
>                 Key: LANG-1369
>                 URL:
>             Project: Commons Lang
>          Issue Type: New Feature
>          Components: lang.exception.*
>    Affects Versions: 3.7
>            Reporter: BELUGA BEHR
>            Priority: Major
>         Attachments: LANG-1369.1.patch
> Add two new Exception classes:
> # FormattedException
> # ParameterizedException
> Both classes provide different mechanisms for creating error messages instead of using
straight string concatenation that can look sloppy and introduces a lot of {{StringBuilder}}
instances into the underlying byte code.  FormattedException uses Java's {{java.lang.String#format}}
method for producing the Exception's detailed message.  ParameterizedException uses Log4j's
implementation of the SLF4J parameterization implementation.

This message was sent by Atlassian JIRA

View raw message