When does an exception becomes considered as an anti-pattern?

Question

As a solutions architect, I design and derive software architecture patterns all the time. In that process, I have encountered numerous exceptions. They are mostly considered exceptions due to an incomplete technology landscape such as missing a crucial component due to regulatory requirements resulting in me granting exceptions to these software architecture patterns. No one likes exception but it is what it is. That's that.

My question - When does an exception becomes considered as an anti-pattern? Or is there that "grey" zone? Or when does an exception becomes a rule? Like a pattern?

Thank you.

Nathan Aw (Singapore)

If you have no other choice due to external influences, does it really matter if it's an anti-pattern? — nvoigt, Apr 04 '20 at 09:22
Do you mean an exception in the sense of a special case that doesn't fit the pattern you are using in general? (As opposed to an exception in the normal software sense like an error occurring?) — Peter Dongan, Apr 04 '20 at 09:42
Fitting the pattern. If it does not fit the pattern it becomes a hack which might result in exceptions — Nathan Aw, Apr 04 '20 at 09:44
This question may be too broad and opinionated for a definitive answer; but it might help if you could give examples of one or two of the patterns you have in mind, and the exceptions you've seen. — jaco0646, Apr 04 '20 at 13:08
related: [What is an anti-pattern?](https://stackoverflow.com/a/27567960/1371329) — jaco0646, Apr 04 '20 at 13:20

score 0 · Accepted Answer · answered Apr 05 '20 at 18:00

When you have to allow something that doesn't fit your architecture, it means that there's something important you didn't know or failed to anticipate, and that your architecture can't accommodate that as designed.

Foresight fails all the time. You have to learn to live and deal with that. Yes, you need to learn everything you can about your customers and their needs, but that's always imperfect. A failure of foresight doesn't indicate any kind of problem with your process unless you'be been negligent, but still each one is an opportunity to learn something about your customers.

That the thing you missed is important is a little more troubling. When there are regulatory requirements in the domain you're designing for, and you don't know about them, and they restrict what you can build... that kinda sounds like something you should have known. I don't know your specific business, though, so maybe there's a reason why that's not true for you.

That your architecture can't accommodate the things you didn't anticipate is the real issue. You should always strive to ensure that the things you don't know or can't anticipate are inconsequential to the overall architecture. This is the part you should really think about: "What assumption did I bake into this architecture that makes it rigid in this dimension? How could I have made my architecture work without presuming to know this stuff that I didn't know?"

Figuring out answers to these questions, and testing those answers in your next project, will make you better every year.

When does an exception becomes considered as an anti-pattern?

1 Answers1