Error Handling

• Error handling is important, but if it obscures logic, its wrong.
• Use exceptions rather than return codes
  • Return codes add clutter (many, many nested if/else status checks and error logs)
• write the try-catch-finally first.
  • They define a scope to work with, and the catch block adds a "consistent state" to always leave the program/method with
• Provide context with exceptions - enough information to know where and WHY the exception occurred - not just a stack trace
• Don't let exceptions break up the "normal flow" of the program - e.g.

          try {
              MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
              m_total += expenses.getTotal();
          } catch(MealExpensesNotFound e) {
              m_total += getMealPerDiem();
          }
  

  should instead be

          MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
          m_total += expenses.getTotal();
  

  That is, the no meal expenses found thing should be handled internally. One solution is to have getMeals() to return an object, which, depending on if meal expenses exist or not, will be one of two types both of which inherit from a parent class defining their interface. This is called the Special Case Pattern.

• Don't return null
  • This results in many annoying if null checks. It's also possible to accidentally miss adding a null check while coding which could break your program at runtime.

• Don't pass null - again, same idea with having if null checks.