There are three main ways to reduce errors in code: tests, asserts and abstractions. All three have advantages and disadvantages and generally deal with different classes of errors.
In this thread, we discuss asserts, not abstractions. Monad is an abstraction. (On the other hand, many people only see tests and forget about two other solutions, which are as important.)
Assertions, yes, in so far as they mean "I know this can't happen, but I can't structurally prevent it in the program in an elegant fashion, with the tools I use". However, I can't see how monads are suddenly going to make this problem disappear.
As for throws/try-catch - beyond assertion use, they also report all problems that are outside your control (like IO failing due to HDD damage, or connection dropping). Those kinds of problems are here to stay.
Sure, monads provide an elegant way to structure code with error conditions, but I don't see a problem with using simple assertions, throws, try-catch to enforce invariants. Personally, I don't care about elegance as much as whether or not it works, as long as it is simple to use and maintain. I can return something like a Maybe/Either, or I can throw an exception - both approaches are fine by me if it forces the programmer to account for error cases.
Throwing is a side effect breaking flow of control for no good reason. It’s takes you down the same path as all other spaghetti code.
Not as much elegance as it is about purity. Minimizing side effects is the number one way to reduce bugs.
It should be the number one guiding principle when creating out reliable software. Which means, you simply cannot use the primitive try catch or similar construct. Don’t break flow of control. Guide it to a terminal value instead.
These days, when I see try-catch and if-else constructs (which is in most codebases) it’s clear there will be bugs over the life of the application.
It’s fine, use them, but there is a world of greatness when you ditch these faulty constructs. Just like ditching OOP constructs. All built on false premises.
If you application is interacting with the outside world, you will be dealing with side-effects, and sometimes error conditions will happen.
For example, today I am working on a service that:
- uses a database
- calls external APIs
- publishes and consumes from a message broker
- interacts with local and remote filesystems over a variety of protocols
All of these things entail error conditions, most of which throw exceptions in the corresponding libraries. Sometimes they are converted to Either/Maybe, and sometimes they are wrapped in "native" checked exceptions.
The important bits:
1. The type system and compiler make sure the programmer has to deal with the error conditions at some point. From a programmer's perspective, a checked exception bubbling up the stack is not very different from returning a monadic object up the stack.
2. The core of the application is entirely pure. No exceptions (in both senses of the word). All side effects are pushed to the boundaries.
pp. 76-77 of Ousterhout's "A Philosophy of Software Design" talk about the issues with boilerplate try-catch. He basically does not approve, as they make readability suffer and often do not do what they advertise (truly catch errors.) I don't know how he would feel about production assertions, but I'm guessing he would buy into it if it helps reduce complexity. In the sense of finding remedies to troublesome bugs--which will occur.
This kind of absolutism only works in the lab and the journal.
The real world of software engineering is enormously varied and each project faces a different set of legitimate constraints and objectives. It's more valuable to discuss how and when to use "assertions, throws, and try-catch[es]" than to pretend that they're universally superceded by some other construct.
In this thread, we discuss asserts, not abstractions. Monad is an abstraction. (On the other hand, many people only see tests and forget about two other solutions, which are as important.)