using Fail-fast approach when developing modular applications

问题

When developing modular applications is it quiet obvious that we need to use Fail-fast systems?

When creating modules if there is an error condition the module cannot handle, it should report the error(like throw an exception..)without worrying who will handle it. It looks like this can be used as a guideline when developing modules. Is there any issues with this?

Edit:Example

In module.dll

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;
       //}
    }
 }

回答1:

There are two categories of critical exceptions I can see: those in which the entire system may have been compromised, and there's not really much that one can safely assume wasn't, and those in which a significant aspect of the system which code is going to expect to "just work", won't, but there's no reason to believe other parts of the system are compromised. In the former case, there's not really much the program can do except die, possibly trying to log what happened if it can do so without corrupting any "main-line" data. In the latter case, though, killing the application would be unduly "rude". A better approach would IMHO be to design the subsystem so that code can "pull the plug" on it to prevent it from causing data corruption, with the consequence that any further attempt to use it (other than an "are you still working" query, whose return value should indicate the problem) will likely throw an immediate exception, but allow those parts of the program that don't need the troubled subsystem to keep running as they were unless or until they decide that there isn't much for them to do without it.

回答2:

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

From the Wikipedia definition. What exactly is the 'next-higher system design level'. Should that not be at least a level that reports the failure so somebody can take corrective measures and fix the problem? Either implemented in a upper layer supplied by the client code that uses your classes. Or a generic error reporter that gets invoked through AppDomain.UnhandledException. Both entirely out of your control.

Throw an exception.

回答3:

Usually, when in C++ generally I implement a critical error scheme, I don't let such critical exceptions even leave the exception handler - I call a 'criticalExit()' method of a globally-accessible class instance, (I usually have one of these to store 'global' methods etc, eg. loggers, object pools), with the exception and a string, (string often just the module and function name). criticalExit() locks a mutex, raises its priority to 'THREAD_PRIORITY_TIME_CRITICAL', opens a 'CriticalError.Log', appends the exception message and string to the file, closes it and calls ExitProcess(1), (Environment.Exit(1)).

..and, just to see, I've tried doing this in C#. It's not so easy to generate a globally-accessible single instance :(

来源：https://stackoverflow.com/questions/10296961/using-fail-fast-approach-when-developing-modular-applications