Exceptions may occur anywhere, even inside a catch (or except in Python) block. It’s not a wrong presumption that people expect them less in there. Anyway, beware of the code you put in these blocks because when an exception occurs you just don’t want to make things worse.

One safe approach to prevent faulty codes in those blocks is to ensure that you are not doing any further processing or data manipulation there. In other words, if you’re re-raising the exception (or logging something) try to use raw data.

For instance, look at this listing:

class Student {
  getCourses() {
    // Query student courses from repository
  }
  makeStudentIdentifier() {
    return `${this.lastname.trim()} ${this.firstname.trim()} (#${this.studentNo.trim()})`;
  }

  doSomeProcess() {
    try {
      const courses = this.getCourses();
    }
    catch (e) {
      console.log("Process failed for %s: %s", this.makeStudentIdentifier(), e);
    }
  }
}

What if, due to some bug somewhere else, Student.studentNo assigned with a number value instead of a string. Calling trim() on a number object causes another exception, terminating the handling you had in mind (here, logging) and returning the control to the first catch block up on the call stack. Not to mention that the original exception, which should be the actual issue to investigate, got masked and you may easily miss it; though somewhere in the middle of the stack trace will be a faint hint to that. So, it’s safer to appreciate raw values and do things with less processing:

console.log("Process failed for %s %s (%s): %s", this.lastname, this.firstname, this.studentNo, e);

About Regular Encounters
I’ve decided to record my daily encounters with professional issues on a somewhat regular basis. Not all of them are equally important/unique/intricate, but are indeed practical, real, and of course, textually minimal.