I understand your position, but I’m not worried about the knowledge of the implementation. I worry about the dependency on the implementation. As I said, clients won’t care if the save is done using a SQL Database or a Message Queue. The declaration of a possible SQLException means clients depend on that RDBMS, and that the clients must recompile if the implementation changes to a Message Queue. That is not low coupling and it is not separation of concerns. IOW. this declaring of possible exceptions, is at odds with two vastly more powerful design principles. Therefore it should be discarded.
Related topics
| Topic | Replies | Views | Activity | |
|---|---|---|---|---|
| FN in S2221: Catching a Generic Exception not reported as issue | 2 | 2446 | April 30, 2020 | |
| Semantic provided for RuntimeException is against java guideline in rule java:112 | 1 | 397 | April 4, 2024 | |
| High availability system and rule "Catch a more specific exception instead of a generic one." | 3 | 848 | September 1, 2022 | |
| S1130 triggers on test methods | 1 | 181 | July 4, 2024 | |
| Split S1166 to two rules: logger vs. new exception | 2 | 1350 | January 30, 2019 |