提前规划异常处理策略

Question

当我查看.NET Framework中的方法时，它可能会抛出几个可能的异常。

从规划的角度来看，我需要问什么来规划和处理这些例外情况？我明白，取决于异常的影响，这将影响在UI层显示它。例如，如果后端对用户体验不透明的进程抛出异常，那么您不希望向用户显示该进程，因为他/她不知道该进程是什么。

感谢

Answer 1

你通常有一个商业逻辑层在你的应用程序，而且你包裹在安全的调用该库中的方法。这些方法甚至可以说出他们可以抛出什么异常，并且如果您愿意，您可能希望以独特的方式处理这些异常。

这里有几个类，可以同时处理突发和自定义异常的例子：

class Program 
{ 
    static void Main(string[] args) 
    { 
     MethodInvokationResult result = SafeActionInvokator.HandleSafely(() => 
     { 
      MyFakeBusinessEngine.DivideTwoNumbers(5, 0); 
     }); 
     if (result.Exception is System.DivideByZeroException) 
     { 
      Debug.WriteLine($"A divide by zerp exception was caught"); 
     } 
     else if (!result.Success) 
     { 
      Debug.WriteLine($"An unknown error occured."); 
     } 
    } 
} 

^你可以看到，你可以用呼叫，并在合理的方式处理它们。

public class MethodInvokationResult 
{ 
    public bool Success { get; set; } 
    public Exception Exception { get; set; } 
} 

^一个简单的结果类

public static class MyFakeBusinessEngine 
{ 
    /// <summary> 
    /// Divides two numbers 
    /// </summary> 
    /// <param name="a">numerator</param> 
    /// <param name="b">denominator</param> 
    /// <returns>the result</returns> 
    /// <exception cref="System.DivideByZeroException">When b is zero, divide by zero exception is thrown.</exception> 
    public static int DivideTwoNumbers(int a, int b) 
    { 
     return a/b; 
    } 
} 

^A有据可查的方法，甚至告诉其他开发人员，预计将抛出什么异常

public static class SafeActionInvokator 
{ 
    /// <summary> 
    /// Executes a method, and if any exception is thrown, will log the error and swallow the exception. 
    /// </summary> 
    /// <param name="methodToExecute"></param> 
    public static MethodInvokationResult HandleSafely(Action methodToExecute) 
    { 
     try 
     { 
      methodToExecute.Invoke(); 
      return new MethodInvokationResult() 
      { 
       Exception = null, 
       Success = true 
      }; 
     } 
     catch (Exception ex) 
     { 
      Debug.WriteLine($"{ex}"); 
      return new MethodInvokationResult() 
      { 
       Exception = ex, 
       Success = false 
      }; 
     } 
    } 
} 

^该方法的包装你调用，将其封装在try catch中允许您以相同的方式处理所有异常，或者将您想要的任何自定义逻辑放在那里。

这可以扩展为一个可以返回任何实际结果值的调用。你可以创建一个通用的结果类，而不是我已经展示的简单结果类。

最后！至于您的实际问题，我会在整个应用程序中创建这些层，并重新引发包含严重等级的任何异常。这些会传播到您的UI层，您可以根据严重性选择要执行的操作。

也许就是这样！

public class MajorException : Exception { } 
public class MediumException : Exception { } 
public class MinorException : Exception { } 
public class UserError : Exception { } 

希望这有助于！

Answer 2

我想把它写成一个评论，但它是长注释文本框...

1. 但也有例外是重要的，以显示用户，因为他们可以自己处理它，用于例如：文件名是非法的。

2. 有一些例外，我觉得很重要，因为他们（用户）会像我的QA团队一样展示用户，例如：某些方法不会更新GUI，他们可能会得出结论：他们应该进一步报告，他们会告诉我的例外，我会发现我的阵列超出界限...

3. 也有例外，推动他们的用户只会混淆他们，像你说的

“他/她本来就是不知道什么是”

例如，例如：

“如果在不透明的后端进程抛出异常”。

那些我为自己节省了异常（在数据库..）..
我总是提醒自己，最终用户有不同的心理比较开发商（ - ：

我希望我理解你的问题正确的方式。