chapter thirteen

13 Error handling and dependency inversion

 

This chapter covers

  • How to layer and structure business logic
  • How to decouple parts from services
  • Many different approaches to dependency inversion

Programming is simple. I recommend it to everyone: writing code, and creating small applications for your own pleasure. Programming is simple. But development — development is extremely hard. So many technological options. So many subtle details. So many controversial requirements. So many things to account for.

Writing code is only a small part of development, and not the most difficult one. If you choose to be a software developer or even a software architect, you’ll have to talk with people, understand their needs, clarify requirements, make decisions, and balance between bad, very bad, and unacceptable solutions. Certainly, you’ll have to learn the domain you’re working in. In their professional lives, developers can change their second occupation many times. Today, you’re a telecom developer, and you have to be fluent in networking, billing, and accounting. Tomorrow, you learn cryptography and start working for a security company. Next time, you’ll move to write search engines, so you’ll buy several new books about natural language processing, algorithms, and data mining. Learning never stops.

13.1 Error handling through architectural layers

13.1.1 Errors versus exceptions

13.1.2 Error domains

13.1.3 Native exceptions handling schemes

13.1.4 Exceptions in Free monad languages

13.2 Functional interfaces and dependency inversion

13.2.1 The Dependency Inversion principle

13.2.2 Service Handle Pattern

13.2.3 ReaderT Pattern

13.2.4 Free monad

13.2.5 GADT

13.2.6 Final Tagless/mtl

13.2.7 Comparison of the approaches

13.3 Summary