catch()-блок как направление потока (вроде)

Обновление на основе обновления OP (структура AOP)

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

Однако в этом случае я прибегаю к совету @silky из комментария, который он оставил здесь, и к предостерегающей записке от @mfx по самому вопросу: зачем вообще ловить? Дизайн вашего программного обеспечения основан на более высоких уровнях проверки возвращаемого значения из вашего метода. Разработчикам очень легко это пропустить или забыть сделать. По крайней мере, если исключение всплывает в стеке и возникает, его можно отметить при тестировании и настроить код. Если возвращаемое значение не проверяется, ошибки могут стать значительно более коварными.

Опять же, я указываю вам на рекомендации Microsoft по обработке исключений для разработчиков. (В аннотированной форме книги, которую я очень рекомендую, есть много заметок о том, почему были приняты проектные решения, в том числе заметки о том, почему они решили — обычно — уклоняться от кодов возврата в пользу исключений.)

Что касается вашего (обновленного) кода, почему это не может быть приемлемым редизайном?

 public WhateverTypeOutputWas GetStuff()
 {
    if(!validation)
        return ActionStatus.DataInvalid;
    //do possible error stuff here
    return data;
 }

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

Судя по тому, как код был написан в вопросе, разработчик получит исключение NullReferenceException, если забудет проверить ваш код состояния. В таком случае, зачем вообще нужен код состояния? Может ли разработчик с уверенностью предположить, что ненулевой возврат любого output означал успешный запуск? А в приведенном выше дизайне мы вырезаем половину метода, правильно всплываем исключения, правильно используем возвращаемые значения (в соответствии с рекомендациями Microsoft по разработке фреймворка) и упрощаем жизнь разработчику, использующему этот метод. Беспроигрышный.

Оригинальный ответ

Зачем вам удалять ценную информацию, содержащуюся в исключении, которое вы перехватываете? Повторить это:

catch(Exception ex)
{
    // Any handling (like logging, etc.) here
    // If no handling, don't bother catching
    throw;
}

и позволить коду более высокого уровня улавливать и определять, что отображать пользователю (если что-то) и (надеюсь) регистрировать подробную информацию в случае необходимости.

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

Что касается исключений как потока управления, я не думаю, что следующее (из вашего исходного вопроса) будет считаться следующим:

if(ex == fooException)
  doThis();
else if (ex == barException)
  doThat();

Я думаю, что рекомендации по проектированию, касающиеся исключений как потока управления, на самом деле относятся к генерации исключений как к способу раннего выхода из циклов (вместо использования break, EG), использованию исключений, когда в коде ничего не пошло не так, как простым ранним возвратам и т. д.

Я указываю вам на официальные рекомендации по разработке исключений от Microsoft; поскольку именно этому я стараюсь следовать в ходе своей работы, и я ожидаю, что разработчики, работающие со мной, будут делать то же самое. (То есть, если у нас нет действительно веских документально подтвержденных причин не делать этого. И опять же, такие случаи редки.)

Помните, что исключения предназначены для исключительных событий в вашем коде — обычно, например, для ошибок. Есть причина, по которой мы не должны проверять коды успеха/неудачи в библиотеке базовых классов .NET — предпочтительная модель в .NET — генерировать исключение, если метод не работает. Таким образом, обработка ошибок относится к try/catch, а коды возврата используются для возврата полезных данных клиентскому коду, использующему ваши методы.

Я думаю, что ваша модель вполне разумна.

И утверждение «не управляйте потоком вашей программы с помощью исключений» немного странно, потому что это именно то, что вы должны делать. Если вы просто продолжаете вести себя так, как будто исключения никогда не было, то я не могу представить, что вы делаете! :)

И я также согласен с тем, что ваше предложение об утверждении «если» довольно нелепо, и любой, кто делает это, должен быть расстрелян.

Но, конечно, что-то вроде

try {
}
catch(SomeException e) { }
catch(Exception e){ }

Разумно.

-- Редактировать:

Обновите, чтобы подтвердить, что я не вижу никакого отношения к этому вашему AOP; это вполне разумно, ИМХО, несмотря ни на что.