Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Are No Silver Bullets: Which Error Handling Style to Pick For a Given Configuration of Constraints?

DZone's Guide to

The Are No Silver Bullets: Which Error Handling Style to Pick For a Given Configuration of Constraints?

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

Kent Beck in his Patterns Enhance Craft Step 3: A Few Good Solutions highlights an important fact about software development:

We encounter repeating configurations of forces/constraints that have only a handful of “solution families” and the optimal solution(s) depend on the relative weightsof these constraints.

For example when deciding what error handling style we should choose when calling an unreliable rutine:

Depending on whether readability, reliability, automated analysis, performance, or future maintenance are most important you could reasonably choose any one of:

  • Exceptions
  • Return value plus errno
  • Exceptional value (e.g. Haskell’s Maybe)
  • Success and failure callbacks

So there is no single perfect error handling style to rule them all.

Kent further explains that the forces shaping most design decisions are generated internal to the process of design, not by external constraints: whether we’re building a barn or an airport, the list of forces influencing the roofing decision is the same – snow, wind, etc. – but their relative strengths may be different. Internal forces in SW development include use of the same bits of logic repeatedly, code made for/by people, etc.. F.ex. the forces influencing naming a variable do not depend on what SW we are building but on its purpose, lifetime, etc. We encounter some configurations of these constraints again and again and a catalogue of design patterns representing the “solution families” mentioned above can guide us towards the most suitable solution for given weights.

Conclusion

When designing a solution, it is helpful to think in terms of these forces and their relative strengths. There is no single superior solution (a.k.a. silver bullet) as different configurations of forces and their weights might be best suited by radically different solutions. Keeping this on our minds might prevent design discussions from dengenerating into an argument.

Download Modern Java EE Design Patterns: Building Scalable Architecture for Sustainable Enterprise Development.  Brought to you in partnership with Red Hat

Topics:

Published at DZone with permission of Jakub Holý, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}