A Monadic Approach to Error Handling in Collection Pipelines

Michael Feathers describes error handling as part of the larger problem of passing the right information through a single sequential pipeline. In his view, a pipeline should be able to keep producing results while also carrying error messages forward when something goes wrong.

He applies that idea to a guitar tablature program. Instead of throwing an exception at the first bad line, he uses a hacked-up Ruby version of Haskell’s Either type so the pipeline can collect errors such as the wrong number of fields, non-numeric values, or out-of-range string and fret numbers. When a check fails, later stages skip their work, and the run ends with either errors or output. He then sketches an implementation by monkey patching Enumerable and delegating through an ErrorEnumerable wrapper.

Reading notes

#

• chained computation is useful for utility programming, but a pipeline still has to manage the information each stage needs
• extra arguments in a sequential flow are presented as a design problem when they are only needed later
• error handling is treated as a special case of that same extra-arguments problem
• passing an empty array is described as the simplest failure response, but it does not preserve error messages
• the tablature program splits input lines into fields and assumes each line has a string number and a fret number
• possible input problems include the wrong field count, non-numeric fields, and values outside the allowed ranges
• exceptions are presented as too coarse because they stop the pipeline at the first detected error
• the Either type is borrowed from Haskell to track both results and errors in one pipeline
• the pipeline with checks records errors and skips later computation after a failure
• the implementation sketch uses a monkey-patched Enumerable and an ErrorEnumerable class with delegation