DEV Community

loading...
Cover image for Code Smell 73 - Exceptions for Expected Cases

Code Smell 73 - Exceptions for Expected Cases

Maxi Contieri
Learn something new every day. - I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Originally published at maximilianocontieri.com ・2 min read

Exceptions are handy Gotos and flags. Let's abuse them.

TL;DR: Do not use exceptions for flow control.

Problems

  • Readability

  • Principle of least astonishment Violation.

Solutions

  1. Use Exceptions just for unexpected situations.

  2. Exceptions handle contract violations. Read the contract.

Sample Code

Wrong

try {
    for (int i = 0;; i++)
        array[i]++;
    } catch (ArrayIndexOutOfBoundsException e) {}

//Endless loop without end condition
Enter fullscreen mode Exit fullscreen mode

Right

for (int index = 0; index < array.length; index++)
        array[index]++;

//index < array.length breaks execution
Enter fullscreen mode Exit fullscreen mode

Detection

This is a semantic smell. Unless we use machine learning linters it will be very difficult to find the mistakes.

Tags

  • Readability

Conclusion

Exceptions are handy, and we should definitively use them instead of returning codes.

The boundary between correct usage and wrong usage is blur like so many design principles.

Relations

More info

Credits

Photo by Greg Rosenke on Unsplash


When debugging, novices insert corrective code; experts remove defective code.

Richard Pattis


This article is part of the CodeSmell Series.

Discussion (0)