Когда проверять на InnerException

Question

Когда следует проверять свойство InnerException класса Exception и его производные? «Рекомендации по исключениям» от Microsoft не дают никаких советов о том, когда следует проверять наличие внутренних исключений. Должен ли я делать это только тогда, когда исключения перебрасываются и попадают в мой код? Должен ли я делать это всегда, даже когда я заключаю в блок try-catch стандартные функции, такие как System.IO.File.Move?

Answer 1

В конечном счете, ответ здесь прост: всякий раз, когда это полезно для вас , что полностью контекстуально. В подавляющем большинстве случаев на самом деле не стоит особо проверять исключение вообще - кроме сообщения об этом; просто "сделать вещь, упс, не удалось" - у вас обычно должно быть больше using и finally, чем catch, IMO - потому что обычно нет ничего полезного, что вы можете сделать с исключением кроме пузыря это вверх.

Однако в некоторых случаях есть полезный контекст. Классическими примерами могут быть AggregateException, TargetInvocationException и TypeInitializationException или что-нибудь от XmlSerializer. Это довольно редко, так что вы не захотите начинать проверять их явно , если только у вас нет веских оснований ожидать их. С точки зрения вашего общего кода сообщения об ошибках: да, имеет смысл регистрировать внутренние исключения, но .ToString() обычно делает это автоматически, IIRC.

В качестве примера из некоторого реального кода, включающего InnerException - в моем сетевом коде есть сценарий, в котором меня не волнует очень специфическая ситуация, обнаруживаемая только с помощью комбинации внешнего и внутреннего исключения ; when делает эту работу за меня:

try
{
    await _server.RunClientAsync(connection.Transport).ConfigureAwait(false);
}
catch (IOException io) when (io.InnerException is UvException uv && uv.StatusCode == -4077)
{ } //swallow libuv disconnect

(все, кроме этого сценария, запутано)

Answer 2

Кто может использовать такую ​​функцию?

Иногда разработчики преобразуют одно исключение (как правило, определенное Microsoft) в другое исключение (обычно это исключение, определенное самостоятельно).

Это может упростить API, например, как в примере, который вы дали с File.Move(). Вместо 7 возможных исключений Microsoft такой API мог бы просто выдать простое исключение «Это не сработало» с деталями внутри, поэтому вашему коду нужно обрабатывать только один тип исключения.

Когда его использовать?

Я бы посмотрел их на этапе разработки при использовании сторонних фреймворков. Если они имеют тенденцию быть пустыми, в написании кода для них нет смысла.

Если вы напишите логгер / трассировщик или общий отладочный вывод, я определенно рассмотрю это.

Исключения, которые я знаю, которые имеют InnerExceptions:

• TargetInvocationException
• AggregateException