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, and I recommend writing code and creating small applications to anyone for fun. However, development is extremely hard. There are so many technological options, subtle details, controversial requirements, and things to account for.

Writing code is only a small part of development, and it is not the most difficult one. If you decide to become a software developer, or even a software architect, you’ll have to talk to 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 occupation many times. Today, you’re a telecom developer and must be fluent in networking, billing, and accounting. Tomorrow, you learn cryptography and start working for a security company. Next time, you may move to writing 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 vs. exceptions

13.1.2 Error domains

13.1.3 Native exception-handling schemes

13.1.4 Exceptions in free monadic 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

Summary