Какое стандартное исключение выдается, если в середине операции произошла ошибка?

Question

Какое стандартное исключение выдается, если в середине операции произошла ошибка?

1

Согласно RTFM, я не должен использовать Exception непосредственно для броска. При перефакторинге кода я изменил большинство из них на

InvalidOperationException если вызов метода неадекватен (неправильные предпосылки, время, состояние и т.д.);
TimeoutExeption когда есть тайм-аут;
ArgumentException (и related - ArgumentNullException и ArgumentOutOfRangeException), когда метод вызывается с неправильными параметрами;

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

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

Sinatr 10 нояб. 2014, в 18:19

Источник

3

Не каждый случай покрывается существующим исключением в .NET Framework. Средний прогресс на самом деле не кажется хорошим исключением для создания, но, учитывая ваше описание проблемы, почему бы вам не создать исключение DeviceCommunicationException, полученное из System.Exception? Кажется, это было бы совершенно уместно и описывало бы реальную проблему, с которой вы столкнулись.
JamieSee 10 нояб. 2014, в 16:43
0

@JamieSee, если я сделаю это один раз, то я не смогу прекратить делать это везде (появится больше DeviceCommunication.. появятся исключения);) Так что нет ничего более-менее по умолчанию ? InvalidOperationException действительно подходит (для пользователя метода причиной является неправильный вызов, в то время как устройство не было на 100% работоспособным , его проблемы есть). :)
Sinatr 10 нояб. 2014, в 16:48
0

Это всегда что-то вроде суждения с такими вещами. Microsoft предоставляет небольшое руководство по дизайну исключений по адресу msdn.microsoft.com/en-us/library/ms229014.aspx, которое стоит посмотреть. Мое собственное мнение таково, что исключения должны описывать реальную проблему, а не фазу конкретного процесса. Я также пытаюсь выяснить, могу ли я уменьшить проблемы, которые могут привести к исключению. Целесообразно ли некоторое время опрашивать устройство, чтобы увидеть, достигло ли оно рабочее состояние, а затем, если нет, выдать исключение TimeoutException?
JamieSee 10 нояб. 2014, в 17:02
1

Без более конкретного вопроса, хороший ответ не может быть предложен. Но если говорить о сбое связи, если вы не хотите определять пользовательское исключение, я бы сказал, что IOException - хороший выбор. Даже пользовательское исключение должно наследовать IOException. В качестве альтернативы, в зависимости от точного характера ошибки, может быть целесообразным возможное исключение InvalidDataException (т. Е. Связь работает, но что-то не так с самими данными ... неправильный формат, поврежденные байты и т. Д.)
Peter Duniho 10 нояб. 2014, в 19:13
0

Объявите свой собственный тип OmgException.
Hans Passant 10 нояб. 2014, в 20:02

Показать ещё 3 комментария

Теги:

c#

exception

vb.net

c++-cli

standards

1 ответ

Ещё вопросы

Не каждый случай покрывается существующим исключением в .NET Framework. Средний прогресс на самом деле не кажется хорошим исключением для создания, но, учитывая ваше описание проблемы, почему бы вам не создать исключение DeviceCommunicationException, полученное из System.Exception? Кажется, это было бы совершенно уместно и описывало бы реальную проблему, с которой вы столкнулись.
@JamieSee, если я сделаю это один раз, то я не смогу прекратить делать это везде (появится больше DeviceCommunication.. появятся исключения);) Так что нет ничего более-менее по умолчанию ? InvalidOperationException действительно подходит (для пользователя метода причиной является неправильный вызов, в то время как устройство не было на 100% работоспособным , его проблемы есть). :)
Это всегда что-то вроде суждения с такими вещами. Microsoft предоставляет небольшое руководство по дизайну исключений по адресу msdn.microsoft.com/en-us/library/ms229014.aspx, которое стоит посмотреть. Мое собственное мнение таково, что исключения должны описывать реальную проблему, а не фазу конкретного процесса. Я также пытаюсь выяснить, могу ли я уменьшить проблемы, которые могут привести к исключению. Целесообразно ли некоторое время опрашивать устройство, чтобы увидеть, достигло ли оно рабочее состояние, а затем, если нет, выдать исключение TimeoutException?
Без более конкретного вопроса, хороший ответ не может быть предложен. Но если говорить о сбое связи, если вы не хотите определять пользовательское исключение, я бы сказал, что IOException - хороший выбор. Даже пользовательское исключение должно наследовать IOException. В качестве альтернативы, в зависимости от точного характера ошибки, может быть целесообразным возможное исключение InvalidDataException (т. Е. Связь работает, но что-то не так с самими данными ... неправильный формат, поврежденные байты и т. Д.)
Объявите свой собственный тип OmgException.

mattumotu · Answer 1 · 2015-05-27T12-29-00.000Z

Это зависит от ситуации. Если это веб-служба (или, возможно, веб-сайт), вы можете выбросить 500 внутренних ошибок сервера.

В моей службе С# wcf в некоторых случаях я делаю следующее:

 throw new System.ServiceModel.Web.WebFaultException<string>(
                "Descriptive error message",
                System.Net.HttpStatusCode.InternalServerError);

какая-либо причина для понижения?