Как осуществить рефакторинг вход в систему C#?
В моих сервисах все выставленные методы имеют:
try
{
// the method core is written here
}
catch(Exception ex)
{
Log.Append(ex);
}
Это скучно и ужасно для повторения его много раз. Там какой-либо путь состоит в том, чтобы избежать этого? Есть ли лучший способ сохранить сервисную работу, даже если исключения происходят и продолжают отправлять детали исключения в Log класс?
9 ответов
Вы можете настроить общий метод обработки ошибок для всех неперехваченных исключений следующим образом:
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(UnhandledException);
В зависимости от того, что пошло не так, вы не сможете восстановить из-за ошибки ... но, надеюсь, это даст вам некоторое представление о том, что пошло не так. Если доходит до того, что код вашего приложения не обрабатывает исключение должным образом, этот метод может попытаться повторно инициализировать службу в известное рабочее состояние.
Попробуйте AOP. Это наиболее широко используемое преимущество AOP.
Также смотрите это обсуждение здесь на SO.
Для этого хорошо подошли бы фильтры исключений. Увы, .NET поддерживает их через MSIL, C++/CLI, VB.NET, но не C#.
Предыдущий плакат затронул тему AOP (Aspecte-Oriented Programming).
Я использую PostSharp для базового протоколирования трасс/исключений.
Он довольно прост в использовании и настройке.
Зайдите по этой ссылке и посмотрите учебник.
http://www.sharpcrafters.com/postsharp
- черт, он больше не с открытым исходным кодом... в любом случае, вы можете взять Postsharp1.5 и повозиться с ним, чтобы понять, интересно ли вам это.
Я также никоим образом не связан с PostSharp. Я просто пользователь.
Я придумал полурешание прямо сейчас. Я могу рефакторить код:
public TResult ExecuteAndLogOnError(Func<TResult> func)
{
try
{
return func();
}
catch(Exception ex)
{
// logging ...
}
}
А затем вы можете вызвать его для каждого метода:
return ExecuteAndLogOnError(() =>
{
// method core goes here..
});
Который на 4 строки короче исходного сценария.
In в таких случаях я всегда использую централизованные обработчики ошибок. В WCF это очень просто. Дополнительные сведения: http://www.haveyougotwoods.com/archive/2009/06/24/creating-a-global-error-handler-in-wcf.aspx
В основном, вы просто реализуете интерфейс IServiceBehavior, а затем предоставляете свой собственный обработчик ошибок. Это лучший способ сделать это, потому что вам не нужно писать какой-либо код, обрабатывающий фатальные исключения (я имею в виду исключения, которые вы можете только регистрировать и не знаете, что с ними делать) в ваших методах.
Если все, что вы делаете, это ведение журнала, просто зарегистрируйте ошибку на более позднем этапе ... Нет необходимости регистрировать ошибку заранее. Если вы делаете больше, чем регистрируете ошибку, тогда вам все равно понадобится try..catch. И если вы проглатываете исключения (т.е. просто регистрируете их, а затем продолжаете, как будто ничего не произошло), то, возможно, вы делаете это неправильно ...
Однажды я использовал что-то вроде шаблона функции шаблона для решения такой проблемы. У меня был базовый класс, который делал что-то вроде:
public void Execute()
{
try
{
ExecuteImplementation();
}
catch (Exception ex)
{
// Log ex
}
}
public abstract void ExecuteImplementation();
На каждую операцию веб-службы приходился один производный класс. Каждый производный класс реализовал ExecuteImplementation.
Операции веб-службы:
[WebMethod]
public Result WebOperation(Request request)
{
WebOperationClass instance = new WebOperationClass(request);
instance.Execute();
return instance.Result;
}
Если все, что вы делаете в своем catch, - это регистрация исключения, вы могли бы просто использовать пользовательскую страницу ошибки и позволить ELMAH регистрируйте все свои неперехваченные исключения.