https://github.com/getparthenon/parthenon/wiki/Design-Decision:-Throw-Custom-Exceptions Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code + Explore + All features + Documentation + GitHub Skills + Blog * Solutions + For + Enterprise + Teams + Startups + Education + By Solution + CI/CD & Automation + DevOps + DevSecOps + Case Studies + Customer Stories + Resources * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles + Repositories + Topics + Trending + Collections * Pricing [ ] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this organization All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up {{ message }} getparthenon / parthenon Public * Notifications * Fork 3 * Star 34 * Code * Pull requests 0 * Actions * Wiki * Security * Insights More * Code * Pull requests * Actions * Wiki * Security * Insights Design Decision: Throw Custom Exceptions Jump to bottom Iain Cambridge edited this page Dec 19, 2022 * 4 revisions Pages 3 [ ] * Home * Design Decision: Throw Custom Exceptions + Decision + Reasoning + Support Implications * Design Decisions: Final classes Clone this wiki locally [https://github.com/g] Decision A Parthenon method should not throw exceptions that don't belong to Parthenon. It should catch all third-party exceptions and then throw a Parthenon-owned exception with the third-party exception passed to the new Parthenon exception. If the third-party exception contains valuable custom information for the exception it should be available via the Parthenon exception. Reasoning One of the way implementation details of an interface can be leaked are by third-party exceptions. If the client code catches and handles a third-party exception then they're coupled to the third-party code. The aim of Parthenon is that everything is replaceable with your own implementation having parts of Parthenon code depend on third-party exceptions - which would happen if Parthenon interfaces threw third-party exceptions. And for many parts of Parthenon, the code is usable/extendable/etc by user developers to develop custom applications, if they depend on the third-party exception then their code also becomes dependent on the third-party code. This means if in the future there were to be a change in the third-party code or how the Parthenon code worked internally it would become a breaking change. The reason to pass the third-party exception to the new exception is that the third-party exception will contain valuable information about what happened and we don't want to lose that. User developers would still be able to use the third-party exception, however, it becomes more obvious that such coupling is fragile. And the custom exception should be able to provide the same information. TL;DR - Removes the ability to become dependent on third-party code which improves flexibility. Support Implications This means if someone reports: * A Parthenon interface throws a third-party exception, it must be changed to throw a custom one. * A Parthenon exception does not contain all the information that is available in the third-party exception, it must be added. Footer (c) 2022 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time. You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.