Functional error handling in F#

When we refactor code how can we be confident that we don't break anything?

3 of the most important things that allow us to refactor fearlessly are:

Side effect free - or pure - expressions
Statically typed expressions
Tests

In this article we will solely focus on the aspect of side effects and strictly speaking on how to identify them. Being able to identify side effects in our programs clearly is the precondition for eliminating them.

Why avoid side effects?

Continue reading →

Have you ever wanted to try out PureScript but were lacking a good way to get started?

If you

Have some prior functional programming knowledge - maybe you know Haskell,Elm,F#,or Scala,etc.
Want to solve a small task with PureScript
And want to get started quickly

This post is for you!

In this post we will walk through setting up and implementing a small exemplary PureScript application from scratch.

Continue reading →

In this article I would like to present a minimal implementation of a music data type and everything that is needed to turn that into audible sound from an Elm application.

We will see how to transcribe an existing composition - an excerpt from Chick Corea's Children's Songs No. 6 - and listen to the result right here,embedded in this article.

From a music data type to performance

My colleague Jonas recently pointed out the presentation Making Algorithmic Music by Donya Quick to me. Donya Quick shows how she uses the Haskell library Euterpea to produce algorithmic music.

It got me really excited about the idea of porting this to Elm and to be able to use this in web applications.

In the following we will see the core data types and algorithms from Euterpea ported to Elm. To focus on the core concepts the implementation is stripped down to the minimum that is required to transcribe and perform an existing polyphonic piece of music (for a single instrument).

Continue reading →

This post is about how to implement well structured,and purely functional command line applications in Scala using PureApp.

PureApp originated in an experiment while refactoring out some glue code of an interactive command line application. At the same time it was inspired by the Elm Architecture Pattern,and scalaz's SafeApp,as well as scalm.

To show the really cool things we can do with PureApp,we will implement a self-contained example application from scratch.

This application translates texts from and into different languages. And it provides basic user interactions via the command line.

The complete source code is compiled with tut. Every output (displayed as code comments) is generated by tut.
Continue reading →

In this post we will see how applicatives can be used for validation in Scala. It is an elegant approach. Especially when compared to an object-oriented way.

Usually when we have operations that can fail,we have them return types like Option or Try. We sequence operations and once there is an error the computation is short circuited and the result is a None or a Failure.

Applicatives allow us to compose independent operations and evaluate each one. Even if an intermediate evaluation fails. This allows us to collect error messages instead of returning only the first error that occurred.

A classic example where this is useful is the validation of user input. We would like to return a list of all invalid inputs rather than aborting the evaluation after the first error.

Scala Cats provides a type that does exactly that. So let's dive into some code and see how it works.

Continue reading →

After some initial struggles,the chapter Functional Parsers from the great book Programming in Haskell by Graham Hutton,where a basic parser library is built from scratch,significantly helped me to finally understand the core ideas of parser combinators and how to apply them to other programming languages other than Haskell as well.

While I recently revisited the material and started to port the examples to Scala I wasn't able to define a proper monad instance for the type Parser[A].

The type Parser[A] alias was defined like this:

type Parser[A] = String =>Option[(A,String)] // defined type alias Parser

To test the monad laws with discipline I had to provide an instance of Eq[Parser[A]]. Because Parser[A] is a function,equality could only be approximated by showing degrees of function equivalence,which is not a trivial task.

Also the implementation of tailRecM was challenging. (I couldn't figure it out.)

Using existing abstractions

Continue reading →

Most config libraries use a stringly typed approach.

Some handle runtime failures due to invalid configuration schemas by leveraging data types like Option or Result to represent missing values or errors. This allows us to handle these failures by either providing default values or by providing decent error messages.

This is a good strategy that we should definitely stick to.

However,the problem with default values is that we might not even notice if the configuration is broken. This could potentially fail in production. In any case an error e.g. due to a misspelled config property will be observable at runtime at the earliest.

Wouldn't it be a great user experience (for us developers) if the compiler told us if the configuration schema is invalid? Even better,imagine we could access the configuration data in a strongly typed way like any other data structure,and with autocompletion.

Moreover,what if we didn't have to write any glue code,not even when the configuration schema changes?

This can be done with the costs of an initial setup that won't take more than probably around 5 minutes.

Continue reading →

In this post I will look at a practical example where the combined application (through monad transformers) of the state monad and the either monad can be very useful.

I won't go into much theory,but instead demonstrate the problem and then slowly build it up to resolve it.

You don't have to be completely familiar with all the concepts as the examples will be easy to follow. Here is a very brief overview:

Continue reading →

If your API overflows with Boolean parameters,this is usually a bad smell.

Consider the following function call for example:

toContactInfoList(csv,true,true)

When looking at this snippet of code it is not very clear what kind of effect the two Boolean parameters will have exactly. In fact,we would probably be without a clue.

We have to inspect the documentation or at least the parameter names of the function declaration to get a better idea. But still,this doesn't solve all of our problems.

The more Boolean parameters there are,the easier it will be for the caller to mix them up. We have to be very careful.

Moreover,functions with Boolean parameters must have conditional logic like if or case statements inside. With a growing number of conditional statements,the number of possible execution paths will grow exponentially. It will become more difficult to reason about the implementation code.

Can we do better?

Sure we can. Lambdas and combinators come to the rescue and I'm going to show this with a simple example,a refactoring of the function from above.

This post is based on a great article by John A De Goes,Destroy All Ifs — A Perspective from Functional Programming.

I'm going to take John's ideas that he backed up with PureScript examples and present how the same thing can be elegantly achieved in Scala.

Continue reading →

I'm currently working on an sbt plugin that generates Scala case classes at compile time to model JSON API responses for easy deserialization especially with the Scala play-json library.

The plugin makes it possible to access JSON documents in a statically typed way including auto-completion. It takes a sample JSON document as input (either from a file or a URL) and generates Scala types that can be used to read data with the same structure.

Let's look at a basic example,an app that prints the current Bitcoin price to the console.

Continue reading →

In this post, which is the second part of the series Functional error handling in F# and C#, we will examine an application for parsing command line arguments with error handling.

The functional approach uses Applicative Functors. Applicative Functors and the basics of functional error handling, only with immutable objects and without the use of exceptions, are explained int the first post of this series: Error handling with Applicative Functors in F# and C#.

A complete solution with all the code samples from this series can be found here.

As a starting point I took this F# console application template and reimplemented it with railway oriented error handling in F# and C#. The original version writes error messages directly to the console, which is totally ok in many situations. However, the railway oriented approach offers a bit more flexibility and safety because it will let the caller decide on how to handle the failure cases.

Parsing command line arguments in F#

The simple parser will return a dictionary containing key value pairs of commands and optional values, or a list of errors if the provided arguments cannot be parsed or don't comply to the given specification.

First we will define the models for specifying the arguments information and error cases:

type ArgInfo = { command:string; description: string option; required: bool}

type ClaError =
    | InvalidArgument of string
    | DuplicateCommand of string
    | UnknownCommand of string
    | RequiredCommandMissing of string
    | ValueMissing of string
    | CannotParseValue of string

Then we need a function to parse a sequence of strings to key value pairs, in this case just tuples of type (string * string option). The option in the second value indicates that there can be commands without a value. Commands must be prefixed with either '-', '--' or '/'.

let parse args =
    let (| Command | Value |) arg =
        let m = Regex.Match(arg, @"^(?:-{1,2}|\/)(?<command>[a-zA-Z0-9]+.*)$", RegexOptions.IgnoreCase);
        match m.Success with
        | true -> Command (m.Groups.["command"].Value.ToLower())
        | _ -> Value (arg.ToLower())

    let valueAndTail args =
        match args with 
        | head::tail -> 
            match head with
            | Command _ -> None, args
            | Value v -> Some v, tail
        | [] -> None, []

    let rec parseRec result remaining =
        match result, remaining with
        | Bad _, _ -> result
        | _, [] -> result
        | Ok (parsed,_), head::tail -> 
            match head with
            | Value v -> v |> InvalidArgument |> fail
            | Command cmd -> 
                let value, tail2 = valueAndTail tail
                parseRec (ok (parsed @ [(cmd, value)])) tail2

    parseRec (ok []) args

If the arguments can't be parsed correctly, the function will return a failure that specifies the first bad argument.

Here are some examples called from a C# test project (with the help of some extension methods for C# compatibility and of FSharp.Extras):

// success
new[] { "-x1", "1", "--x2", "2", "/x3", "-x4", "4" }.Parse().Match(
    ifSuccess: (v, _) => Check.That(v).ContainsExactly(
        Tuple.Create("x1", "1".Some()),
        Tuple.Create("x2", "2".Some()),
        Tuple.Create("x3", FSharpOption<string>.None),
        Tuple.Create("x4", "4".Some())),
    ifFailure: _ => Assert.Fail());

/// failure
new[] { "-x1", "1", "--x2", "2", "x3", "-x4", "4" }.Parse().Match(
    ifSuccess: (v, _) => Assert.Fail("succeeded but should fail"),
    ifFailure: errs => Check.That(errs).ContainsExactly(ClaError.NewInvalidArgument("x3")));

Next there are three little checks that will ensure

that there are no duplicates of commands
that all required commands are in the argument list
and that there aren't any commands in the argument list that are not in the definition list

let inList xs x = xs |> List.contains x

let checkArgsContainNoDuplicates definedCmds args =
    args
    |> List.filter (fst >> inList definedCmds)
    |> List.groupBy fst
    |> List.filter (snd >> List.length >> fun x -> x > 1)
    |> List.map fst
    |> List.distinct
    |> List.map DuplicateCommand

let checkAllRequiredArgsExist requiredCmds args =
    requiredCmds
    |> List.filter (not << inList (args |> List.map fst))
    |> List.map RequiredCommandMissing

let checkAllArgsAreDefined validCmds args =
    args 
    |> List.map fst
    |> List.distinct
    |> List.filter (not << inList validCmds)
    |> List.map UnknownCommand

For the sake of DRY and SoC these function can be combined with a function that transforms the error messages into a Result.

let validate x validator =
    let errs = validator x
    match errs with 
    | [] -> ok x
    | _ -> Bad errs

Combining everything

let parseArgs args argInfos =
    let definedCommands = argInfos |> List.map (fun x -> x.command)
    let required = argInfos |> List.filter (fun x -> x.required) |> List.map (fun x -> x.command)

    let createDict _ _ x = dict x

    parse args
    >>= fun parsedArgs -> 
        createDict
        <!> validate parsedArgs (checkArgsContainNoDuplicates definedCommands) 
        <*> validate parsedArgs (checkAllRequiredArgsExist required)
        <*> validate parsedArgs (checkAllArgsAreDefined definedCommands)

First we transform the argument information into a list of all defined commands, required and not required, and into a list of only all required commands.

Then we define the function createDict that takes three arguments that each represents one of the checks. createdict transforms only the last argument into a dictionary. When the function will be lifted into the Result type, the 3 arguments are needed to apply the results of the 3 checks. The 1st and the 2nd argument will be ignored if all the checks pass. But when lifted, if at least one of the checks fails, the error messages of all failed checks will be propagated.

Next, the arguments are parsed with parse args. This returns a Result<(string * string option) list, ClaError>. Then createDict is combined with the result of parse args with >>= (infix bind) because if the parsing fails we cannot validate. bind is used because it bypasses all subsequent operations in case of a failure.

The validations are then composed with the applicative style so that error messages will be accumulated.

Dependent and independent checks

The general rule here is that dependent values are combined with the monadic style using bind, and independent values are combined with the applicative style using e.g. apply and lift. This is described in more detail here by Scott Wlaschin.

The three validation functions are all independent. The outcome of any of them doesn't influence the outcome of the others. Therefore we can combine them with apply.

They do depend however on the outcome of the parser function. So they have to be combined with that using bind.

Example

Here is a test that shows the behavior:

var defs = new[]
{
    new ArgInfo("x", FSharpOption<string>.None, true),
    new ArgInfo("y", FSharpOption<string>.None, false),
    new ArgInfo("z", FSharpOption<string>.None, false),
};

new[] { "-y", "lizard", "-a", "Anton", "-z", "Zealot", "-z", "Zoo" }
    .ParseArgs(defs)
    .Match(
        ifSuccess: (dictionary, _) => Assert.Fail("should fail but was success."),
        ifFailure: errs => Check.That(errs).ContainsExactly(
            ClaError.NewDuplicateCommand("z"), 
            ClaError.NewRequiredCommandMissing("x"), 
            ClaError.NewUnknownCommand("a")));

Conclusion

We have seen an example of functional error handling in practice. The functional error handling approach leads us to defining small function that each do only one thing. In the parseArgs functions all the small checks are composed together using the railway oriented style.

The details of error handling like e.g. accumulating messages or bypassing subsequent operations are abstracted away.

There is no way to access an invalid value. Therefore no exceptions can be thrown that break the flow of the program. Also, there is no need to wrap the calling code inside try catch statements.

The railway oriented style enforces us to always handle both the success and the failure cases.

I disclaim that the design can still be improved. One issue e.g. is that the list of argument information can contain invalid state like duplicate definitions of commands. So a next step could be to make this invalid state unrepresentable by design. This parser is very simplistic and I focused on readability. Other than making functions tail-recursive e.g., performance was not a primary concern.

The code from this post can be found here.

In the next post of the series Functional error handling - parsing command line arguments in C# we will see how the same functional error handling behavior can be implemented in C#.

Leif Battermann

Functional Programming Fu

Identify Side Effects And Refactor Fearlessly

Why avoid side effects?

PureScript Case Study And Guide For Newcomers

Elm And The Algorithm Of Music

From a music data type to performance

Interactive Command Line Applications In Scala –Well Structured And Purely Functional

How To Use Applicatives For Validation In Scala And Save Much Work

Parsers in Scala built upon existing abstractions

Using existing abstractions

Strongly Typed Configuration Access With Code Generation

Error and state handling with monad transformers in Scala

Use lambdas and combinators to improve your API

Modelling API Responses With sbt-json –Print Current Bitcoin Price

Leif Battermann

Functional Programming Fu

Functional error handling – parsing command line arguments in F#

Parsing command line arguments in F#

Combining everything

Example

Conclusion