"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
- Mission-critical systems can crash as a result of run-time errors in a program, causing possible harm to life and limb.
- Mission-critical systems need to be fault tolerant.
- Even minor bugs can cause you to bomb out of a program.
- FaultTolerance allows mission-critical systems to continue running when errors occur.
- Clutters code with additional processing.
- 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.
procedure BUCK_STOPS_HERE -- in Ada
begin -- CRITICAL PROCESSING
-- do critical processing
when others => -- this is the "catch all"
-- handle errors within this procedure
end BUCK_STOPS_HERE ;
, 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
WHEN OTHERS THEN ROLLBACK TO SAVEPOINT foo;
The management version of BuckStopsHere
can also be an AntiPattern
Given the above description, MicroManagement
can be better described as TheBuckStopsOneLevelBelowMe?
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.