Не хотите бросать исключение, должен ли я вернуть собственный класс, содержащий массив bool и string?

Question

В вашем коде есть определенные области, которые вы не хотите остановить выполнение программы, например, во время проверки в магазине ecomm.

Я думал о создании особого типа «возвратный», который выглядит как:

public bool SpecialReturn 
{ 
    public bool IsSucess {get;set;} 
    public List Messages {get;set;} 
} 

Я мог бы положить перечисление там, чтобы вернуть ReturnType и т.д., если я хотел.

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

Это хорошая практика?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Вы пришли из прекрасного мира C, не так ли?

да, вы можете это сделать. но это не было бы полезно ... ваш код может все еще бросить из ClassLibrery и обработки кодов ошибок, хорошо сосет ...

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

вы должны использовать исключение, но также только в исключительных случаях ...

Answer 4

это хорошая практика?

Я бы сказал НЕ.

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

Если вы используете Visual Studio, для этого есть хороший фрагмент кода, называемый Exception.

[Serializable] 
public class MyCustomException : Exception 
{ 
    public MyCustomException(string myMessage) 
    { 
     MyMessage = myMessage; 
    } 

    protected MyCustomException(SerializationInfo info, StreamingContext context) 
     : base(info, context) 
    { 
    } 

    public string MyMessage { get; private set; } 
} 

//... 

throw new MyCustomException("Hello, world!"); 

Answer 5

Если функция может преуспеть и вернуть результат, или сбой и не вернуть результат, вы можете использовать тот же шаблон, который делает Microsoft в нескольких местах. TryParse - прекрасный пример.

int result; 
if (Int32.TryParse("MyStringMayFail", out result)) 
{ 
// Succeeded result is usable 
} 
else 
{ 
// failed result is undefined and should not be trusted. 
} 

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

Это не так просто создать собственную реализацию методов TryParse, они обычно связаны с методами Parse, которые генерируют исключения, если что-то не удается во время обработки.