关于c#：在开发模块化应用程序时使用Fail-fast方法


using Fail-fast approach when developing modular applications

在开发模块化应用程序时，我们是否需要使用快速故障系统？

在创建模块时，如果存在模块无法处理的错误条件，则应报告错误(如引发异常..)，而不必担心谁将处理该错误。看起来这可以作为开发模块时的指导方针。这有什么问题吗？

编辑：实例

在DLL模块中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class SomeClass:ISomeInterface
{

    public void CreateFile(string filename)
    {
       //The module have no idea who calls this. But there is something wrong        
       //somewhere so  throw an exception early. The module writer has no control over
       //how the exception is handled. So if this exception is not handled by the
       //Client Application the application can potentially crash.Do he need to worry
       //about that?
       if(filename == null)
       {
          throw new ArgumentNullException("Filename is null");
       }

       //I think the following is bad. This code is making sure that a module
       //exception wont crash the application.Is it good?
       //if(filename ==null)
       //{
       //Logger.log("filename is null");
       //return;
       //}
    }
 }

我可以看到两类重要的异常：一类是整个系统可能已经被破坏了，而我们可以安全地认为没有什么，另一类是系统的一个重要方面，即代码将要"正常工作"，但没有理由相信系统的其他部分重新妥协。在前一种情况下，除了死区之外，程序实际上不能做太多的工作，如果它能够做到这一点而不破坏任何"主线"数据，那么可能会尝试记录所发生的事情。但是，在后一种情况下，终止应用程序将是不适当的"粗鲁"。更好的方法是设计子系统，这样代码就可以"拔掉"子系统上的插头，以防止它导致数据损坏，从而导致任何进一步尝试使用它(而不是返回值应该表明问题的"您还在工作"查询)都可能引发立即的异常，但允许这些PA不需要故障子系统继续运行的程序的RTS，除非或直到他们决定没有它没有什么可做的。

相关讨论

A fail-fast module passes the responsibility for handling errors, but not detecting them, to the next-higher system design level.

从维基百科的定义。"下一个更高的系统设计水平"到底是什么？这不应该至少是一个报告失败的级别，以便有人能够采取纠正措施并解决问题吗？或者在使用类的客户机代码提供的上层实现。或通过AppDomain.UnhandledException调用的一般错误报告程序。都完全失控了。

引发异常。

相关讨论

通常，在C++中，通常我会执行一个关键的错误方案，我不让这些关键异常甚至离开异常处理程序——我称之为"全局访问类"实例的"临界AlxIt()"方法(我通常有一个来存储"全局"方法，例如日志记录器、对象池)，除此之外，还有一个字符串(通常是字符串)。只有模块和函数名)。critical exit()锁定互斥体，将其优先级提高到"threadu priorityu timeu criticalerror.log"，将异常消息和字符串附加到文件，关闭它并调用exitprocess(1)，(environment.exit(1))。

…而且，只是想看看，我试过用C来做这个。生成一个全局可访问的单个实例并不容易：(

相关讨论