2011-01-24 2 views
2

У меня есть исключение членства, которое выглядит следующим образом:Является ли это правильным способом использования исключений?

public enum MembershipError 
{ 
    EmailNotFound, 
    EmailNotConfirmed, 
    IncorrectPassword, 
    EmailExists 
} 

public class MembershipException : ApplicationException 
{ 
    public MembershipError MembershipError { get; set; } 

    public MembershipException(MembershipError membershipError) 
     : base(Enum.GetName(typeof (MembershipError), membershipError)) 
    { 
     MembershipError = membershipError; 
    } 
} 

Должен ли я использовать перечисление в моем исключении или сделать исключение для каждого перечисления? Потому что тогда я был бы положить логики при отлове исключения, как это:

try 
{ 

} 
catch (MembershipException exception) 
{ 
    switch (exception.MembershipError) 
    { 
     case MembershipError.EmailExists: 

      break; 
      //etc. 
    } 
} 

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

ответ

5

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

Например

public bool TryGetMembershipData(
    string user, 
    out Data data, 
    out MemberShipError error) { 
    ... 
} 
+2

Я собираюсь объединить эти 2 'out' в 1 класс и вернуть его. –

+0

@Lolcoder: Но как насчет возвращаемого значения bool? Это своего рода использование методов Try. Кроме того, подумайте об использовании «Tuple», а не о создании нового класса. – Brian

3

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

+0

Мой служебный слой выдает эти исключения, веб-уровень/в действии ловит их, генерирует правильный json и возвращает его в представление. –

+0

У вас есть контроль над уровнем обслуживания? –

1

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

0

Это может показаться не очень PC, но я считаю, что разработка программного обеспечения не является религией, которая заставит вас соблюдать строгие обеты только ради него. Есть, конечно, теоретические объяснения Dos и Donts, есть тонны Продуманные Вредный очерки, , но они не всегда применимы к вашему собственному делу?

Давайте просто прагматично:

  1. MembershipException Ваш класс специализируется достаточно, и прежде всего, это легко поддерживать с его MembershipError ENUM.

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

Просто сохраните его так: прост в обслуживании и прост в чтении.

0

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

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

Смежные вопросы