Code Smell 80 - Nested Try/Catch

Code Smell 80 - Nested Try/Catch

Maxi Contieri
·Jun 16, 2021·

2 min read

Subscribe to my newsletter and never miss my upcoming articles

Play this article

Exceptions are a great way of separating happy path versus trouble path. But we tend to over-complicate our solutions.

TL;DR: Don't nest Exceptions. Nobody cares of what you do in the inner blocks.


  • Readability


  1. Refactor

Sample Code


try {
} catch (e) {
    if (e instanceOf DBError){
      try {
      } catch (e) {

//Nested Try catchs
//Exception cases are more important than happy path
//We use exceptions as control flow
try {
} catch (transactionError) {
    this.withTransactionErrorDo(transationError, transaction);

//transaction error policy is not defined in this function
//so we don't have repeated code
//code is more readable
//It is up to the transaction and the error to decide what to do


We can detect this smell using parsing trees.


  • Exceptions


Don't abuse exceptions, don't create Exception classes no one will ever catch, and don't be prepared for every case (unless you have a good real scenario with a covering test).

Happy path should always be more important than exception cases.


More Info


Photo by David Clode on Unsplash

Thanks to Rodrigo for his inspiration

Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that can be made.

Karolina Szczur

This article is part of the CodeSmell Series.

Share this


Technical Opinions are my own. I don't have the revealed truth.

Software Design is a creative activity. These are hints and not rigid rules.

I write on BackEnd Business Systems and OOP Design. My advice/experience might not suit other systems.

You can write me at info(at)