Buck Stops Here

"The buck stops here," is a phrase first coined by U.S. President HarryTruman and is a reference to PokerGame, at which Truman was an expert. In some games of poker even though there is one person who physically deals the cards, the player who for purposes of determining the order of betting is the "dealer" is designated by a small round chit called a "buck". The buck gets rotated by one position for each different hand. By saying "the buck stops here" Truman indicates that he will be the dealer for this and every hand. He will call the game, and always act in the last position, with the most information, in the most powerful seat. The conventional meaning of the phrase is the assumption of final responsibility for certain actions or for a project. When someone says "the buck stops here" they mean that even though an underling might screw up, they (the person in charge) will either fix it, or accept the consequences personally.

Very informative! I chose this name because one of the aliases of the ChainOfResponsibilityPattern (given as this pattern's complement) is "Pass the Buck." -- BobKauffmann?

Pattern: Buck Stops Here

Problem

Mission-critical systems can crash as a result of run-time errors in a program, causing possible harm to life and limb.

Forces

Mission-critical systems need to be fault tolerant.
Even minor bugs can cause you to bomb out of a program.

Solution

In languages that facilitate ExceptionHandling (AdaLanguage, CeePlusPlus, JavaLanguage, etc.) use "catch all" exception blocks as a standard default method of trapping and handling errors and run-time exceptions thrown within functions.

Consequences

  Pros

FaultTolerance allows mission-critical systems to continue running when errors occur.

  Cons

Clutters code with additional processing.

Relationships

Complement of the ChainOfResponsibilityPattern as applied to error propagation.

Known Uses

In both the A/N BSY-2 combat system and the portions of the Aegis combat system that were coded in Ada, employing this pattern was standard practice.

Code Example

  procedure BUCK_STOPS_HERE -- in Ada
  begin -- CRITICAL PROCESSING 
-- do critical processing
  exception
when others => -- this is the "catch all"
-- handle errors within this procedure
  end BUCK_STOPS_HERE ;

In CeePlusPlus and JavaLanguage, try using the base class for all exceptions as the type of the parameter of the catch block (exception and Throwable, respectively), and encompass all of the processing logic of your function within the try block. Someone let me know if this works.

But see DontCatchExceptions. Catch-all blocks can obscure legitimate processing errors. When there is a bug, you want it reported all the way up to the programmer, and as quickly as possible so that the system can start functioning correctly. When the problem is environmental, then you would like to know how to fix it. In short, this is not a substitute for building failsafe systems. Generally a system will need a catch-all only in very few places. If they litter your codebase, then you will have any number of silent-failure bugs which you can only wonder about.

The standard response is to log everything. But see also DontCryWolf?. Logs can have low SignalToNoiseRatio when every exception is logged whether you expected it or not. Deal intelligently with what you expect, don't try to handle something you don't expect, and solve "we're thoroughly screwed" by carefully placing failsafes with really good problem diagnostic information. Use that diagnostic information to debug your software with the intended goal that the user will know about every problem personally and that the user never sees problems.

I HaveThisPattern and have used it very successfully in the AtsProject and the DenaliProject, with one exception: I use BuckStopsHere exactly once, in the root (top-most, "main()") method. -- JimLittle

I think what this essentially means is not only catching all lower-level exceptions, but also making sure they're all handled properly, always recovering gracefully and returning a best-effort result if needed. This means that it is always safe to call a method that says that the buck stops here. Of course, catching every and any exception possible is impossible, so it's more practical to say that the buck stops here with respect to a certain group of exceptions, for instance a method reading some stuff from a db in Java catching all SQLExceptions, returning null when they occur. Or an example in PL/SQL:

  CREATE OR REPLACE PROCEDURE foo
  IS
  BEGIN
    SAVEPOINT foo;
    bar;
    baz(3);
  EXCEPTION
    WHEN OTHERS THEN ROLLBACK TO SAVEPOINT foo;
  END;
  /

-- AalbertTorsius

The management version of BuckStopsHere can also be an AntiPattern called MicroManagement.

Given the above description, MicroManagement can be better described as TheBuckStopsOneLevelBelowMe?.

See PassTheBuckAntipattern.

I HaveThisPattern as well. However, there can be negative consequences for using BuckStopsHere. It can have the effect of discouraging error handling at lower levels. This can result in lower resolution of error reporting (i.e., we know an error occurred, but don't quite know what happened), or it can cause excessive error handling at the top level of control. It can actually increase the complexity of the error handling. It seems to me that BuckStopsHere should only be used as a safety net, not a general error handling solution.