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.

See also http://www.trumanlibrary.org/buckstop.htm

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 Forces Solution Consequences
Relationships Known Uses Code Example
  procedure BUCK_STOPS_HERE -- in Ada
	-- do critical processing
	when others => -- this is the "catch all"
	-- handle errors within this procedure

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:
    SAVEPOINT foo;
-- 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.

View edit of August 20, 2005 or FindPage with title or text search