> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/general-paradigms/sad-paths.md). # 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hanfak.gitbook.io/workspace/general-paradigms/sad-paths.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.