2010-11-15 3 views
2

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

try 
    { 
    someComponent.DoStuff(); 
    } 

    catch (Exception ex) 
    { 
    textLabel= ex.Message; 
    } 

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

+3

Похоже на звуковое решение. –

+0

Является ли компонент переупаковкой всех исключений в System.Exception? Если бы вы не справились с обычными уловами. Если это хотя ... удачи. – asawyer

+1

Просто нет. Вы не представляете, насколько серьезным является это исключение. –

ответ

1

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

Так что в плане просто добавить информацию в самом основной форме - бросая новое исключение с некоторым дополнительным текстом, пока еще проходит первоначальное исключение:

catch (Exception ex) 
{ 
    throw new Exception("This is more about where the exception occurred", ex); 
} 

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

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

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

+0

Следует отметить следующее: если вы используете ComponentSpecificException, важно правильно настроить причину с исключенным пойманием, вызвав initCause в ComponentSpecificException и выбросив то, что он возвращает, или передав исключение catch исключение (или исключение RuntimeException) конструктор. В противном случае вы потеряете информацию о трассировке стека, как отметил @Jeff. См. Комментарий к классу на [java.lang.Throwable] (http://download.oracle.com/javase/6/docs/api/java/lang/Throwable.html) – corriganjc

+0

Вы оба заметили «* never * забываете установить внутреннее исключение "? Просто любопытно (-: – Murph

+0

D'oh, извините Murph. Мои навыки понимания прочитанного вчера были на рекордно низком уровне. –

0

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

2

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

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

2

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

0

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

0

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

Затем уведомите пользователя о возникшей проблеме и предложите им возможность попробовать еще раз (если это интерактивная программа).

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

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