两个异常管理问题 [英] Two exception management questions

问题描述

关于网站的异常管理，我有几个问题:

• 在catch块中我可以有一个带有处理异常方法的静态类，该方法可以像这样处理异常:

    catch(异常异常){抛出ExceptionHandler.HandleException(...);} 

  其中ExceptionHandler.HandleException是一个静态方法，它返回类型为System.Exception的变量.这是一个好习惯吗?这种方法可能存在问题吗?它是线程安全的吗?

• 在我的应用程序中，我有一个DAL层，由业务层调用，而业务层由UI调用.那么，是否只是重新抛出所有Custom异常，以使它们冒泡直到显示它们的UI，而System.Exception类型却被记录，而我在catch块中抛出一个自定义异常，是一种好习惯?例如在DAL和业务层中:

   捕获(CustomExceptionBase ex){扔;}捕获(sysEx异常){ICustomExceptionBase ex =新的SysException(sysEx);ex.Handle();抛出BusinessException(服务您的请求时出现问题");} 

  在这样的UI层中

   捕获(CustomExceptionBase ex){//当自定义异常冒出时；在屏幕上向用户显示文本的代码}捕获(sysEx异常){ICustomExceptionBase ex =新的SysException(sysEx);ex.Handle();//在屏幕上显示错误；} 

  此处CustomExceptionBase实现ICustomExceptionBase并继承Exception.SysException&两者都继承自CustomExceptionBase.

感谢您的时间...

编辑在system.Exceptions块中重新抛出的意图是，如果出现致命错误，例如数据库连接丢失或类似错误，那么我将其记录到技术服务台并返回故障单编号，然后将其重新抛出，以便用户知道发生了什么错误，这是您的后续参考号码.对于DAL层或业务层中的所有自定义例外，我将其一直扩展到显示文本的UI.

解决方案

我怀疑某些答案至少完全取决于您的体系结构.在第一种情况下，这完全取决于 ExceptionHandler.HandleException 的确切功能.它是根据某些条件生成新的异常还是只是返回原始异常?

其线程安全性还是不完全取决于其实现.例如，在以下琐碎的情况下，我会说这是线程安全的:

 公共静态Exception ExceptionHandler.HandleException(Exception ex){退货} 

在其他情况下，它很容易不是线程安全的.例如:

 公共静态字符串消息；公共静态Exception ExceptionHandler.HandleException(Exception ex){消息= ex.ToString;睡眠(2000);返回新的Exception(message);} 

后面的示例显然具有在另一个线程处于睡眠状态时更改该消息变量的范围.

对于第二个...在应该处理异常的地方应该处理异常.没有硬性规定.如果代码的某些部分可以实现从异常中恢复(或愿意跳过该异常)，则应在此点而不是更早地捕获它.如果一个异常确实是致命的，那么什么也不要试图抓住它，并假装否则，因此您应该让它冒泡直到顶部，并执行类似的操作来警告您的用户事情已崩溃，并且您需要重新启动或执行任何操作./p>

因此，这实际上取决于您的自定义异常的含义.如果它们只是表示您想重试此操作"，则表示异常与数据完整性已被破坏:0 == 1"不同.这两个都可能是自定义的，因此您可以真正决定在哪里处理事情.

I have a couple of questions around exception management for a website:

• in the catch block can I have a static class with a handle exception method that handles the exception like so:

     catch (Exception ex)
      {
          throw ExceptionHandler.HandleException(...);
      }
  

  where ExceptionHandler.HandleException is a static method that returns a variable of type System.Exception. Is this a good practice? Any possible problems with this approach? Will it be thread safe?

• In my application I have a DAL layer that is called by the Business layer and the Business layer is called by the UI. So, is it a good practice to just re-throw all Custom exceptions so they bubble up right up to the UI where they get displayed whereas System.Exception types get logged and I throw a custom exception in the catch block? for eg in DAL and Business Layer like so:

      catch (CustomExceptionBase ex)
      {
          throw;
      }
      catch (Exception sysEx)
      {
          ICustomExceptionBase ex = new SysException(sysEx);
          ex.Handle();
          throw BusinessException("Some problem while serving your request");
      }
  

  In the UI layer like so

      catch (CustomExceptionBase ex)
      {
          //when custom exception bubbles up; code to display text to user on screen
      }
      catch (Exception sysEx)
      {
          ICustomExceptionBase ex = new SysException(sysEx);
          ex.Handle();
          //display error on screen;
      }
  

  Here CustomExceptionBase implements ICustomExceptionBase and inherits Exception. SysException & BusinessException both inherit from CustomExceptionBase.

Thanks for your time...

EDIT The intent of rethrowing in the system.Exceptions block is so that if there is a fatal error like database connection lost or something similar then I log it for the technical helpdesk and return a ticket number and rethrow the same so the user knows that something went wrong and this is your reference number to follow up. For all custom exceptions in the DAL layer or Business layer, I just bubble it up all the way to the UI where the text gets displayed.

解决方案

I suspect some of the answers at least are entirely down to your architecture. In the first case it all depends on what ExceptionHandler.HandleException does exactly. Does it generate a new exception based on some criteria or is it just going to return the original exception?

Whether its thread-safe or not entirely depends on its implementation. For example in the following trivial case I'd say it was thread safe:

public static Exception ExceptionHandler.HandleException(Exception ex)
{
    return ex;
}

In other cases it could easily be not thread safe. eg:

public static string message;
public static Exception ExceptionHandler.HandleException(Exception ex)
{
    message = ex.ToString;
    sleep(2000);
    return new Exception(message);
}

The latter example clearly has scope for the message variable to be changed by another thread while this one is asleep.

As for the second... Exceptions should be handled where it makes sense to handle them. There is no hard and fast rule. If some part of the code can effect a recovery from an exception (or is willing to skip over it) then catch it at that point and not earlier. If an exception is truly fatal then nothing should be trying to catch it and pretend otherwise so you should just let it bubble right up to the top and do something like alert your user that things have crashed and that you need to restart or whatever.

So really it depends on what your custom exceptions mean. If they just mean "You want to retry this" then that is different from an exception saying "Data integrity has been compromised: 0==1". both of these may be custom so really its for you to decide where to handle things.

这篇关于两个异常管理问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！