Общий способ добавления информации в Throwable без создания нового Throwable

Question

Было бы полезно добавить общий способ добавления информации в Throwable без создания нового Throwable?

Я часто вижу такой код:

try { 
    foo(); 
} catch(Exception e) { 
    throw new Exception(e.getMessage() + " extra info=" + blah, e); 
} 

было бы лучше вместо добавления Throwable.setProperty (ключ String, значение строки), так что приведенный выше код становится следующим?

try { 
    foo(); 
} catch(Exception e) { 
    e.setProperty("extra info", blah); 
    throw e; 
} 

Дополнительная информация может печатать (по одной строке) между сообщением и списком стеков.

Преимущества: 1. Не требуется создавать новые Throwables, чтобы добавить дополнительную информацию. 2. Трассировки стека не будут иметь многослойных следов причин (и, следовательно, их легче читать) 3. Снизить затраты на создание дополнительных стеков.

Answer 1

В целом, я думаю, что лучше использовать стандартные идиомы в таких случаях. В этом случае стандартный идиома обернуть исключение, например:

try { 
    foo(); 
} catch (Exception e) { 
    throw new MySpecificException("extra info=" + blah, e); 
} 

Кроме того, в общем-то лучше не поймать общие исключения. Если вы хотите поймать и добавить информацию в RuntimeException, сделайте это и создайте новое RuntimeException. В противном случае подумайте о том, какие проверенные исключения вы хотите поймать и выбросить.

Answer 2

Связанные исключения уже занимаются удалением избыточных фреймов штабеля. То есть вы увидите только один кадр стека, указанный один раз. Это вопрос мнения, но я считаю, что отсутствие цепного исключения является недостатком.

Отказывать расширение RuntimeException было бы хорошо. Это может помочь в этом отношении.

Промежуточные фреймы стека, возможно, захотят добавить свой собственный контекст, когда раскладывается стек. Это может привести к сбиванию свойств. Должен существовать механизм борьбы с этим, например, стек значений для данного имени свойства.

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

Answer 3

Как обычно, с Исключениями, это очень зависит от сценария. Несмотря на то, что вы должны попробовать и быть конкретными для тех исключений, которые вы ловите, вы также хотите быть явным в отношении причин исключений в текущей области и не увеличивать исключения, выброшенные из другой области. Если вам нечего добавить, что может помочь вызывающему абоненту и не может выполнить какое-либо действие в ответ на конкретное исключение, просто разрешите его распространять. Если есть информация из вашей области действия, которая будет уместна вызывающему, отбросьте свое исключение на свою информацию, прикованное к исключенному исключению. Ключ здесь - область. Всегда выводить результаты из текущего объема и позволять другим областям делать то же самое.