Какое исключение .NET я должен использовать для сигнализации о сбое внешнего приложения?

Question

Я новичок в использовании C # и .NET, но я хочу попробовать играть красиво и повторно использовать системные компоненты.

В поддерживаемом мною коде есть несколько случаев, когда мы запускаем внешние инструменты и приложения, которые выглядят примерно так:

using (var Setup = Process.Start(SetupInfo) )
{
    Setup.WaitForExit(SetupTimeout);
    if (!Setup.HasExited )
        throw new TimeoutException(
            "Setup did not complete within the expected time");
}

Я пытаюсь добавить проверкукоды выхода также для тех внешних инструментов, которые имеют четко определенные коды выхода, то есть что-то вроде этого в блоке «using»:

switch ( Setup.ExitCode )
{
    case 0: 
        break;
    case 1: 
        throw new SetupFailedException("Setup execution failed");
    case 2: 
        throw new SetupFileNotFound("Setup did not find required files");
    default: 
        throw new ExternalErrorException("Setup failed for some other reason");
}

... где первые два будут производными от общего исключения ExternalErrorException».Но есть ли какое-то существующее общее исключение, которое я мог бы повторно использовать для этого, то есть, чтобы сигнализировать о том, что внешний процесс не запустился, как ожидалось, вместо того, чтобы изобрести свой собственный?

Answer 1

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

Что делает очень вероятным, что бессмысленно продолжать выполнение кода, с этого момента дела идут вниз. В конце концов, необходимая программа не была установлена, поэтому при попытке ее использовать весьма вероятно появление дополнительных исключений. Теперь без хорошего объяснения, почему это не удалось, причина true заключалась в том, что установщик не работал.

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

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

Answer 2

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

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

Answer 3

Почему вы бросаете исключения?Из того, что вы говорите, кажется, у вас есть особая логика, которую необходимо выполнить на основе результатов установки.Exception - это , а не способ сигнализации бизнес-логики.Во всяком случае, у меня будет перечисление, соответствующее кодам выхода, которые затем можно будет проверить.

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

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

Answer 4

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

Лично я бы использовал System.Runtime.InteropServices.ExternalException для всех случаев и просто добавил причину сбоя (если она доступна на основе кода выхода и / или других данных) в сообщение об исключении. Если вам когда-нибудь понадобится добавить подклассы для конкретных случаев, они могут быть производными от ExternalException вместо пользовательского типа.

Answer 5

Как кто-то другой уже поставил под сомнение ваши мотивы, я не буду этого делать.Мне нравится, что вы часто чувствуете необходимость повторно использовать исключения .NET, так как это то, что больше всего кажется ООП, но иногда это оправдание, потому что я могу быть ленивым.

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