# Sad Paths

* Dealing with exceptions
  * Can use a Jetty Exception Handler, or JMS Error handler, which is the last stage at which we can handle an exception
    * useful for
      * retriable scenarios
      * putting on dead letter queues
      * Handling exceptions after catching them
* Transient exceptions
  * things that break, that cause exceptions, but are not permanent
  * ie a service is down
  * should be retriable
  * retriable up to a point then be a failure
* Failures
  * exceptions that lead to complete failure
  * not retriable
  * does not mean the app should break
  * maybe a flow ends in failed state, and some intervention needs to be taken to fix or to allow it to be replayed
* Validations
  * User input should be validated
  * Internal service to service, should not
    * as long as both services are well tested
    * use of pact tests
* Aim of dealing with exceptions/sad paths,
  * never lose a failure or success
  * There must be an audit, either in logs or database
* Exceptions should always be logged, and keep the stack trace
* Pattern for dealing with failures
  * using client libraries can sometimes hide the failure
    * give nice message,
    * can throw exception, and deal with it, possibly store state for that flow and message and/or code (which should be able to get from client output)
    * can ppossibly get the throwable, which you can make visible too
  * If lots of exceptions, or possible exceptions that can be bubbled up from a class (or it's calls to delegates)
    * can wrap the class, with a decorator, that will have try/catch and can deal with the exception there
    * this simplifies the logic of the business/usecase class
    * if some actions cannot be caught, be bubbld up to an error handler
    * This is useful, if need to deal with all exceptions the same
      * ie log, store in db, and /or send report to user with info
      * any specific actions that need to be taken cannot use this process, and this will impact the logic (making it more complex)
* Not all exceptions are sad paths
  * some exceptions can be considered normal and part of normal processing
    * Should be handled specificially (ie wrap or retry or use outdated data) and not as a whole (bubble up to a catch all exception gatherer)
  * Wrapping these in business specific exceptions and bubbling up (either to be thrown and reported to user) is essential
    * This can allow us to get more information, which we report to the user with