Каковы лучшие практики для возврата ошибок из функций?

Question

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

Function Test() as String
  ' Do something
  If error occured Then   
    Return "Some error message"
  Else   
    Return ""    
End Functon

Answer 1

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

Вот краткий обзор: http://www.vbdotnetheaven.com/UploadFile/rajeshvs/dotnetException04162005022135AM/dotnetException.aspx

Answer 2

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

Когда вы писали код в своем вопросе, вы, вероятно, предполагали, что он будет назван так:

String message = Test();
// process the message for errors.

Многие разработчики просто обойдут обработку сообщения или даже вызовут вашу функцию следующим образом:

Test();
// go about your business, happily ignoring the error message

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

Answer 3

Как сказали Эрик и Билл, исключения являются нормальным способом распространения ошибок в .NET. Однако есть ситуации, когда они не подходят - например, проверка ввода пользователя. На данный момент есть несколько альтернатив:

• Используйте код ошибки (например, enum), чтобы указать тип ошибки. Например, у вас может быть один код для «Пароль был слишком короткий», а другой для «Пароль не содержит цифр» и т. Д.

• Используйте сообщение об ошибке так, как вы предложили в вопросе. Я лично использовал бы нулевую ссылку для случая «все было в порядке» или, возможно, заставил бы метод возвращать логическое значение (действительное / недействительное) и иметь параметр out для сообщения об ошибке. Использование строки плохо для интернационализации, но во многих отношениях проще (позволяет избежать дополнительных поисков, проще добавить новый тип ошибок и т. Д.), Чем версия кода ошибки. Это может быть хорошо для внутреннего приложения, которое никогда не нужно будет интернационализировать.

Я подчеркиваю, что это только варианты, где исключения не имеют смысла - в противном случае исключения - это путь.

Answer 4

Шаблон «запрос-ответ» может помочь в обработке ошибок и многих возможных проблем. Например, в процедуре аутентификации кредитной карты у вас может быть:

class CreditCardAuthenticationRequest {
    string CreditCardNumber;
    string FullName;
    ...
}

class CreditCardAuthenticationResponse {
    CreditProcessorStatusCode Status;
    CreditProcessorWarnings[] Warnings;
    CreditProcessorErrors[] Errors;
    Exception Exception;
    ...
}

Теперь внезапно вся ваша обработка ошибок и проверка могут быть помещены в аккуратный маленький пакет. Пример приложения Patterns in Action от DoFactory.com широко используется.

Answer 5

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