Надеюсь, это просто. Я работаю над большой кодовой базой, общее качество хорошее, но иногда вы получаете некоторые из них:
try
{
// Calls a .NET remoting method.
}
catch
{
throw;
}
Обратите внимание, что нет никакой логики finally, и catch не указывает никаких исключений и не делает ничего, кроме того, что я предоставил над. Однако я знаю, что перехват и повторное выбрасывание могут изменить стек вызовов в деталях исключения. В чем я не уверен, так это в том, что такое поведение здесь связано именно с вызовом удаленного взаимодействия .NET.
Безопасно ли удалить этот try-catch? Насколько я понимаю, это так, но я подумал, что сначала дважды проверю на предмет странного поведения.
Повторное использование , как вы показали , не должно изменять стек вызовов, если только в удаленных исключениях нет чего-то особенного. (Я знаю, что есть некоторые специальные аспекты, но я не думаю, что они вступают в игру здесь.) Это та вещь, которая действительно теряет информацию:
catch(Exception e)
{
throw e; // Not throw;
}
Мое предположение заключается в том, что некоторые разработчики включили это просто для того, чтобы они могли поставить точку останова на линии throw
. Я бы избавился от этого.
Хотя в большинстве случаев это, вероятно, избыточный / ненужный код, try { .. } catch { throw; }
может подавить оптимизацию компилятора и встраивание метода JIT. В основном это наблюдается в трассировках стека вызовов.
Таким образом, «может» быть побочным эффектом , на который полагаются в другом месте.
Возможно, «ошибка» будет зависеть от этой детали реализации, особенно без явной документации о таком ожидаемом поведении ... и тем более, что это не является гарантией.
См. . Релиз НЕ отлажен: 64-битная оптимизация и встраивание методов C # в стеки вызовов Release Build , предшествовавшие даже этому старому вопросу.
Хотя код кажется избыточным, код try-catch также не будет устранен во время компиляции .