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]