ASP.NET meta:resourcekey

Создайте новый соответствующий Exception, который может управлять пользовательскими данными, такими как значение ввода unitLevel.

public class UnitCreationException extends Exception {
   ...

   // Package-private constructor.
   // Don't expose too much to the outer world
   UnitCreationException(
        final String message,
        final int unitLevel,
        final Throwable cause) { ... }
}

Поймайте Exception на месте, записав, что, по вашему мнению, может оказаться полезной информацией, доступ к которой можно получить только в этот момент

public Unit createUnit(final int unitLevel) throws UnitCreationException {
    final List<String> widgetClassNames = getUnitsClasses();

    try {
        return (Unit) Class.forName(widgetClassNames.get(unitLevel))
                           .getConstructor(Player.class)
                           .newInstance(getOwner().get());
    } catch (InstantiationException 
            | IllegalAccessException 
            | IllegalArgumentException 
            | InvocationTargetException
            | NoSuchMethodException 
            | SecurityException 
            | ClassNotFoundException e) {
        // Do not log the Exception stack-trace here, you'll do that
        // at a hihger level
        logger.error("Error message");

        // Re-throw your custom and more meaningful Exception
        throw new UnitCreationException("Error message", unitLevel, e);
    }
}

На более высоком уровне вы будете вынуждены чтобы понять, что UnitCreationException

try {
   final Unit unit = createUnit(10);
} catch (final UnitCreationException e) {
   // Here you can log the Exception stack-trace
   logger.error("Error message", e);

   // Do something with the information contained in the custom Exception
   final int erroredUnitLevel = e.getUnitLevel();
   ...
}

Всегда были споры о проверенных Exception с против RuntimeException с. Я считаю, что это хороший вариант использования для проверенного, особенно если это часть библиотеки, которая может использоваться несколькими клиентами.

Вы хотели бы иметь возможность каким-то образом восстановиться после такой ошибки, не останавливая все приложение (возможно, с помощью логики повторной попытки).

Я был свидетелем того, как разработчики использовали Optional<T> в качестве возвращаемого типа, только чтобы избежать null. Это контрпродуктивно , так как вы теряете действительную причину ошибки, и вы не можете отреагировать на это в своей собственной ветви (ветка catch)

В конечном счете, Java предлагает вам способ настройки Exception, так что используйте эту функцию.