If Ok

AntiPattern Name: If Ok

Context: Almost every language that requires error handling code.

Problem: Error handling can obfuscate business logic and make code much harder to maintain. People think that because error handling is a good thing, that ALL error handling code is good. In reality, only 'good' error handling code is good.

The Fallacy: "Statements ABC should only execute if everything is ok. Therefore, I should put ABC inside an IfOk block".

Example:

if(ok) {
  callA()
  callB()
  callC()
},
else
   throwException()

Scale this up and we get:

if(ok){
  callA()
  if(A_ok){
    callB()
    callC()
    if(B_Ok AND C_ok){
       callD()
       callE()
       callF()
       callG()
    },
    else
       throwException("Method A failed")
  },
  else
     throwException("Method B or C failed")
},
else
   throwException()

The business logic should have been as simple as ABC but the error-handling code has caused problems:

• Obfuscated business logic.
• Error handler is far from the error.
• Lots of unnecessary nesting

Actual Solution: Use the IfError pattern.

• Separate error-handling code from business logic code.
• Remove unnecessary levels of nesting.
• Keep error handlers near the errors
• Less code

Example:

callA()
if(A_error)
   throwException()

callB()
callC()
if(B_error OR C_error)
   throwException()

callD()
callE()
callF()
callG()

Related AntiPatterns:ArrowAntiPattern

Applicable Positive Patterns:IfError FailFast

AntiPatternCategory: DevelopmentAntiPattern

Also Known As: [other names]