The Malaise Era: The "good enough" ISP router solution

In general, I'm absolutely a neophyte: I love learning about and building new things. I'm CTO of a medical device company, my favorite hobby is learning about new software practices and languages, and once, in order to learn microcontroller programming, I created a weight sensor that would count the number of "sessions" my cat had in the litterbox and send me an email when it reached a threshold count (not going to admit what that threshold count was...).

But when it's come to adopting the cutting edge at home, more often than not I find myself waiting unitil someone can polish those sharp edges before adopting them myself. While I'm pretty good at solving tech issues, I'd rather be able to treat my home appliances as appliances, and save my tech support stamina for the day job.

That's why, for home networking, I've always gravitated to a simple "set it and forget it" setup: the standard all-in-one Wi-Fi modem-router-firewall-switch that comes out of the box from the ISP. A couple years ago, I was feeling fancy and added a mesh network to improve coverage out in the yard and in my back office. But still quite vanilla. I was intrigued with trying DD-WRT/Tomato/Open WRT router firmware but didn't really see the cost-benefit of having to maintain it correctly and securely. (This is probably a fallacy - I'm sure there are good examples where I would have been more secure with one of the above than using/trusting my router's commercial firmware. But at least superficially, the default setup seemed like a "solved problem" - why mess with it?)

But recently, I was working on a side-project to set up a Raspberry Pi nature cam in my backyard (more on that someday...), and had to do some "simple" port-forwarding that proved inordinately difficult and confusing. The real issue was hard to pin down—it ended up being somehow related to a "double-NAT" issue between the ISP router, the Google WiFi mesh, and my ISP's DNS (as Scott Hanselman says, "It's always DNS")—but, it took close to a full day to resolve, and ultimately the solution was to turn off the ISP router's DHCP and firewall altogether. This worked, but it was both limiting and unsatisfying, as I had to hang my entire network off the Google Mesh, which is quite bare-bones when it comes to router features and customization.

Based on the above and similar experiences, along with seeing some new products come on the market, I found myself interested to see if I could add faster performance and new capabilities to my network, without breaking the bank, requiring learning major sysadmin skills, or requiring significant routine maintenance.

Requirements

1. Partitioned network One of the things I really wanted to customize was to partition and monitor my network into different profiles: guest access, general device access, minimal access for IoT devices like the nature cam, and machines I use for work. In particular, it would have been be great to have a partitioned "virtual network" for my work machines that could 1) isolate traffic more securely, to minimize exposure to my company's network when I access office/cloud resources via VPN, and 2) potentially provide a persistent VPN connection to those resources, versus continually having to use software clients for that.

2. Faster connectivity I also wanted a faster 2.5GbE hard-wired connection and modern Wi-Fi 6 wireless access for my back office (neither of which was available via the Google mesh system), and a firewall VPN that could support the bandwidth of my 1-gigabit internet fiber internet line (I was currently limited to software clients to achieve this, and the connection reliability and performance were surprisingly device dependent).

3. Network storage Finally, it would be nice to take advantage of a 2.5GbE (or even a minimal 10GbE) "backbone" and have a high-speed local NAS to house local copies of all our valuable data (in addition to their cloud counterparts currently in Dropbox Family and Google Photos). I didn't want to splurge for multi-thousand-dollar commercial solutions for this, but the OSS storage world is becoming quite mature, and the commodity hardware available for DIY solutions are getting very interesting.

Initial Firewall Research: A Goldilocks problem

After researching (read: mostly watching lots of YouTube videos and the occasional Reddit thread—thanks ServeTheHome, Jeff Geerling, NetworkChuck, Lawrence Systems), it seemed like the prevailing wisdom on evolving my firewall/router system was to either go with a "prosumer" Unifi Dream Machine solution, or to run pfSense on my own hardware (Netgate sells pfSense hardware, too, but gigabit-capable VPN appliances get expensive).

Neither exactly fit the bill. On one hand, the Dream Machine was a nice commercial solution, but while Ubiquity has something of a cult following, they tend to have mixed reviews on how they update their products. Also, I didn't need the Wi-Fi of the Dream Machine, since I wanted to have a separate wireless solution (see below). Here's a video showing Network Chuck's infatuation with the thing:

On the other hand, while pfSense seemed quite full featured (and an interesting learning opportunity), I didn't feel like I could "dabble" and still feel like I was creating a reliable and secure appliance that I could learn in a weekend and leave alone for months at a time. And since I needed some decent hardware VPN performance, I couldn't run a simple Raspberry Pi or similar single-board computer solution. Constructing and maintaining a full set of server hardware was going to be both expensive and error-prone (see Lawrence Systems' video explainer on selecting the right hardware and details on virtualization performance for pfSense). Might as well spring for the $699 Netgate 6100 and be done with it...but, ouch that's a bit expensive:

Firewalla Purple: A "just right" user friendly and feature-rich gigabit firewall, router, and VPN

Enter Firewalla, a company that has been innovating to democratize enterprise-level firewall capabilities that are simultaneously affordable and user-friendly. Beyond the great feature set, ease of configuration, and polished mobile software client, the thing that probably impressed me the most was their track record of responding to customer feedback and continuing to evolve their hardware solution to achieve high performance on low-cost SBC platforms. After reading a bit and comparison shopping, I was ready to bite the bullet and purchase their Firewalla Gold for $439. I didn't necessarily need the gigabit switch included in the package, but it seemed to be the right combo of software and hardware features otherwise.

Luckily, I sat on this decision for a minute. Because while I was deciding to commit, they launched Firewalla Purple—a $299 step-down option with everything I needed, and nothing I didn't. Solved.

One of the nice things about Firewalla Purple is that it's very much based on the Gold. And so once any beta software stack issues are resolved, one can expect to have a very similar, full-featured experience as their other products, which tend to have great reviews. I'll be sure to follow-up as things stabilize with any concerns or gotchas I discover.

The Rest

Once I had the firewall "keystone" in place, the rest was downhill. Below, I detail what I used to round out my network. Note: prices are what I paid in July 2021 - as of writing this, the chip shortage has caused current prices to surge higher. I'm using my original prices with the hopes they're more reflective of long-term pricing.

QNAP 10G/2.5G Network Switch

The next piece of the puzzle was the main switch to receive the output of the Firewalla Purple. I ended up splurging on this $339 QNAP QSW-M2108-2C Layer 2 managed switch with 2x10G SFP+/RJ45 combo ports and 8x2.5G ports. This gives me 2.5G for all my downstream devices, a fast 10G "backbone" that I can use to connect my back office to the main house, an additional 10G line that I can use to attach a future DIY NAS, and VLAN capabilities to partition my devices on separate networks as needed.

Netgear 10G/1G Network Switch

For now, I've run a Cat 7 network cable to the back office, so a $199 Netgear GS110MX 10-Port unmanaged switch (8x1G, 2x10G/2.5G) in the back office does the job, allowing my main machine to connect above 1Gbps. This was a compromise in cost, but it's not fantastic value - I feel like the cost of this unit should be $50 cheaper as-is, or add $50 and upgrade the 1G channels to 2.5G. I expect since commodity 2.5G networking is starting to take off, we'll see more affordable options soon.

Unifi WiFi 6 Long-Range Access Points

Two $179 U6-LR-US access points cover our whole property well: one at the center of the house and one for the back office.

Netgear PoE+ 5-port Managed Gigabit Switches

Maybe overkill for just powering the access points (vs buying a PoE injector for each), but these two $49 GS305EP 5-port managed PoE+ switches give me the ability to add other home automation and/or video camera devices in the future. Getting the managed versions will allow me to toggle power to those devices remotely, versus having to physically access the hardware.

Sabrent 2.5Gbps USB-C adapters

For a surprisingly-affordable $35, Sabrent NT-S25G USB-C to 2.5GbE adapters are quick and quiet. Assuming they continue to prove reliable, they will be my go-to for most systems. (Sabrent also offer a 10G Thunderbolt 3 option for $160, for those machines without a PCI-E NIC option)

Wrapping up

At the end of the day, I now have a brand new managed 10G/2.5G + Wi-Fi 6 home networking setup with a sophisticated and user-friendly firewall, PoE+ smart device expansion options, and room for a high-performance DIY home NAS upgrade, all for the price of an entry-level MacBook Pro. Pretty happy with the value here. As a caveat, I'm definitely still in the honeymoon period, so I'll be sure to update as things progress.

Hope this walk-through was helpful! What hardware/software combos do you use? I'd be very interested in hearing from other people's expertise and experiences down in the comments below.

Thanks for reading, and talk soon. David

Here I'd like to share some simple code samples that exercise these ideas. If you'd like, you can follow along by browsing the code samples in my repo here: https://github.com/lightw8/rop-examples-csharp

First off, after a little refactoring and paring down a bit¹, here's the sum total of the ROP helpers from last time, along with a Compose extension method to chain functions together:

using System;

namespace RailwayOrientedProgramming
{
    public class Error
    {
        public Error(string message) => Message = message;
        public string Message { get; init; }
        public override string ToString() => Message;
    }

    public class Result<T> : Choice<T, Error>
    {
        public static implicit operator Result<T>(T value) => new Result<T>(value);
        public static implicit operator Result<T>(Error error) => new Result<T>(error);

        public Result(T item) : base(item) { }
        public Result(Error item) : base(item) { }
    }

    public class Choice<A, B>
    {
        public Choice(A item) { Item = item!; }
        public Choice(B item) { Item = item!; }

        public dynamic Item { get; }

        // equality and string representation delegated to member (Item)
        public override bool Equals(object? obj) => Item.Equals(obj);
        public override int GetHashCode() => Item.GetHashCode();
        public override string ToString() => Item.ToString();
    }

    public static class RopExtensions
    {
        public static Func<T1, T3> Compose<T1, T2, T3>(this Func<T1, T2> func1, Func<T2, T3> func2) =>
            value => func2(func1(value));

        public static Func<Result<TIn>, Result<TOut>> Bind<TIn, TOut>(this Func<TIn, Result<TOut>> func) =>
            choice => choice.Item switch
            {
                Error e => (Result<TOut>)e, // ugly cast because C#
                TIn tIn => func(tIn).Item switch
                           {
                               Error eOut => eOut,
                               TOut tOut  => tOut,
                               _          => new Error($"Invalid argument")
                           },
                _       => new Error($"Invalid argument")
            };

        public static Func<Result<TIn>, Result<TOut>> Map<TIn, TOut>(this Func<TIn, TOut> func) =>
            Bind<TIn, TOut>(input => func(input)); // implicit upcast of return type of func to Result<TOut>

        public static Func<TIn, TIn> Tee<TIn>(this Action<TIn> deadEndFunction) =>
            input => { deadEndFunction(input); return input; };

        // Removed, as it's the same signature as Tee (with Result<TIn> as the TIn type)
        // public static Func<Result<TIn>, Result<TIn>> Audit<TIn>(this Action<Result<TIn>> deadEndFunction) =>
            // input => { deadEndFunction(input); return input; }; // perform the action and return the input
    }
}

And now, let's contrive some overly-simple examples to exercise the helpers, using the minimalistic style of "top-level statements," a new capability in C# 9.

I've created five separate functions with different signatures: two error-generating functions (maybeAdd3 and maybeInverse), one simple function, expected to always succeed (subtract7), and two "audit" functions that either perform an action on simple "1-track" data value (printFloats) or on a 2-track Result type (printFinalResult).

using System;
using System.Linq;
using RailwayOrientedProgramming;

// 1) error-generating switch function
Func<int, Result<long>> maybeAdd3 = val => val switch
{
    13 => new Error("Unlucky!"),
    _  => (Result<long>)(val + 3)
};

// 2) simple 1-track function
Func<long, float> subtract7 = val => val - 7f;

// 3) 1-track "dead-end" action (no return)
Action<float> printFloats = val => Console.Write($"The value is currently {val}.\t");

// 4) error-generating inverse function
Func<float, Result<double>> maybeInverse = val => val switch
{
    0f => new Error("Inverse!"),
    _  => (Result<double>)(1f / val)
};

// 5) 2-track "dead-end" action (no return)
Action<Result<double>> printFinalResult = result =>
{
    Action action = result.Item switch
    {
        double d => () => Console.WriteLine($"Happy path! Final value is {d}"),
        Error e  => () => Console.WriteLine($"Error path :( ({e.Message})")
    };
    action();
};

var compositeFunc = maybeAdd3         // 1) error-generating function
    .Compose(subtract7.Map())         // 2) map a simple 1-track function
    .Compose(printFloats.Tee().Map()) // 3) tee and map a simple dead-end action
    .Compose(maybeInverse.Bind())     // 4) bind error-generating inverse function
    .Compose(printFinalResult.Tee()); // 5) tee a 2-track dead-end action

Console.WriteLine("\nOutput:\n");
var results = Enumerable.Range(0, 16) // 0,1,2,...,15
    .Select(compositeFunc)            // perform composite operation
    .ToArray();                       // force enumeration

For each of the methods, I use one or more of the adapter methods to shape the inputs and outputs into the 2-track railway model. Notice:

1. that Bind isn't needed at the beginning for maybeAdd3 because it's starting with a simple int, not a 2-track Result

2. how Map "lifts" the simple signature into the Result domain

3. how Tee is used to intercept the chain and perform actions on the intermediate values

4. that if we were to output the result (e.g. what you'd do at an API boundary), we would do something similar to printFinalResult, where we'd have to decide how to "roll-up" the two tracks into one

Here's the output of the code:

Output:

The value is currently -4.      Happy path! Final value is -0.25
The value is currently -3.      Happy path! Final value is -0.3333333432674408
The value is currently -2.      Happy path! Final value is -0.5
The value is currently -1.      Happy path! Final value is -1
The value is currently 0.       Error path :( (Inverse!)
The value is currently 1.       Happy path! Final value is 1
The value is currently 2.       Happy path! Final value is 0.5
The value is currently 3.       Happy path! Final value is 0.3333333432674408
The value is currently 4.       Happy path! Final value is 0.25
The value is currently 5.       Happy path! Final value is 0.20000000298023224
The value is currently 6.       Happy path! Final value is 0.1666666716337204
The value is currently 7.       Happy path! Final value is 0.1428571492433548
The value is currently 8.       Happy path! Final value is 0.125
Error path :( (Unlucky!)

In the end, there are 12 fully-processed values, and two errors (one because we hit the unlucky value 13, and one for an unallowed inverse operation). Also, note the side-effect of printing the value 0 succeeds, even though the final result is an Error, which occurs later on. ALL inputs, however, propagate through to the end, regardless. That's quite satisfying. I haven't included exception-to-error mapping, but ultimately those functions would end up looking just like the "maybe" functions.

A few nits:

1. I ended up demonstrating this with Func-type functions, but this would work with methods as well.

2. In terms of readability, I felt being able to call extension methods on the Funcs directly was more concise/clear to illustrate the point, but this would work equally well by calling the fully-qualified ROP helpers with method delegates.

3. Scott Wlaschin points out that you can also hide the "ROP-ified" functions behind a new namespace, so you can use the same names as before, where the extension methods aren't visible at the top-level.

4. Compared with F#, where function composition and pipe operators built into the language, Compose is a bit annoying. It would be great to have these in the language. I've always thought C# was a bit too restrictive with operator overloading, and it would be powerful to be able to define these ourselves and provide for this kind of functionality. But, I see how the language could get messy quickly if they let us expand the operators willy-nilly. Functions are becoming more and more like first-class citizens in C#, though, so maybe we'll also see some new features or operators emerge around composing them, too.

Final Thoughts

I haven't yet exercised this model in any production code, but there are certainly some very nice qualities about it, particularly in the high-level clarity of the code's intent, and how the error approach nudges you toward TDD-style development where the errors get explicitly handled and handed off to an appropriate consumer.

One of the places it might be most appealing is in massively parallel compute code, where you don't want to break the propagation for spurious edge cases (that yield NaN, for example), or where you want to skip computation at various points if the values fall outside of certain tolerances or desired ranges. On the flipside, there is a significant amount of abstraction happening to achieve this functional model, and so we lose the tight data-locality and compiler optimizations you'd get from classic "for-loop" iteration and direct application of logic, versus the functional parameters passed in. The provided Choice type is also a bit heavyweight, as it requires runtime dynamic computations. I'd like to do some more reading to understand how functional programmers have worked toward these high-performance scenarios.

In any case, it's been a fun journey to work through this talk. Thanks to Mr. Wlaschin for the clear, interesting, useful, and funny [presentation](favorite talks). What are your thoughts about this style of programming? What would be your major barriers to adopting this in your code?

Thanks for reading, and talk soon. David

¹ I ultimately removed Audit, as it shares the same generic signature as Tee. That is, at least how I'm understanding the talk. Haven't reviewed other work on the topic...not yet, at least!

Here, I'd like to enumerate some of the code samples I built in C# as I "coded along" at home. I haven't yet compared these to any other online code samples on the topic, but you can check my work and see some extra resources on the topic on his ROP page here. There, he also issues a warning that this approach isn't always recommended, and has some downsides, too. I'll leave that analysis for another day.

Error-generating functions

An error-generating function acts as a "switch." A TIn input yields either a success type TOut output (the normal "happy path" output), or an Error:

SuccessOrError ErrorGeneratingFunction(TIn input) { ... }

Instead of returning a "lowest common denominator" C# object type which could contain either result, we can use a discriminated union or "choice" type to represent the output with strong(er) typing. Here's a minimal implementation of an "A or B" Choice type:

public class Choice<A, B>
{
    public Choice(A value) { Value = value; }
    public Choice(B value) { Value = value; }

    public dynamic Value { get; }

    // equality and string representation delegated to member (Value)
    public override bool Equals(object? obj) => Value.Equals(obj);
    public override int GetHashCode() => Value.GetHashCode();
    public override string ToString() => Value.ToString();
}

I say "stronger" typing because the Value parameter is still dynamically typed. (True Discriminiated Unions, a core feature of F#, appear to be coming in C# , which is exciting.) With this in place, the Result type becomes:

// Result implementation
class Result<TOut> : Choice<TOut, Error>
{
    public static implicit operator Result<TOut>(TOut value) => new Result<TOut>(value);
    public static implicit operator Result<TOut>(Error error) => new Result<TOut>(error);

    public Result(TOut value) : base(value) { }
    public Result(Error error) : base(error) { }
}

As a convenience, I added implicit conversions from either of the two individual output types (TOut and Error, here), into the Result<TOut> type.

Using this structure, the signature of the error-generating switch function becomes:

// switch function signature in Func-form
Func<TIn, Result<TOut>> switchFunction; 

// ...and an example method
Result<float> MaybeInverse(float val) => val switch
{
    0f => new Error("Inverse!"),
    _  => (Result<float>)(1 / val)
};

Bind

Bind is an "adapter block" that glues these error-generating functions together into a two-track model, so that the happy paths compose, and the failure path short-circuits by forwarding any previous Errors.

// Bind signature in Func-form
Func<Func<TIn, Result<TOut>>, Func<Result<TIn>, Result<TOut>> bind;

// ...and implemented as a method
Func<Result<TIn>, Result<TOut>> Bind<TIn, TOut>(Func<TIn, Result<TOut>> switchFunction)
{
    return choice => choice.Value switch
    {
        Error e => (Result<TOut>)e,
        TIn tIn => switchFunction(tIn).Value switch
        {
            Error eOut => eOut,
            TOut tOut  => tOut
        }
    };
}

Map

A map is an adapter block that turns (or "lifts") a 1-track function into a two-track function²:

// Map signature in Func-form
Func<Func<TIn, TOut>, Func<Result<TIn>, Result<TOut>> map;

// ...and implemented as a method (in terms of bind)
Func<Result<TIn>, Result<TOut>> Map<TIn, TOut>(Func<TIn, TOut> oneTrackFunction)
{
    return Bind<TIn, TOut>(input => oneTrackFunction(input));
}

Tee

Tee is an adapter block that turns a "dead-end" function (or Action) into a one-track function:

// Tee signature in Func-form
Func<Action<TIn>, Func<TIn, TIn>> tee;

// ...and implemented as a method
Func<TIn, TIn> Tee<TIn>(Action<TIn> deadEndFunction)
{
    return (TIn input) => { deadEndFunction(input); return input; };
}

These are "side-effect" functions that might write to the database, send an email, log an action, print to screen, etc. Now that we have a one-track function, we can use Map to turn it into a two track function. Let's call that composite capability "Audit":

Audit

// Audit signature in Func-form
Func<Action<TIn>, Func<Result<TIn>, Result<TIn>>> audit;

// ...and implemented as a method (in terms of Map and Tee)
Func<Result<TIn>, Result<TIn>> Audit<TIn>(Action<TIn> deadEndFunction)
{
    return Map(Tee(deadEndFunction));
}

// ...or alternatively, directly in terms of Bind
Func<Result<TIn>, Result<TIn>> Audit<TIn>(Action<TIn> deadEndFunction)
{
    return Bind<TIn, TIn>(input => { deadEndFunction(input); return input; });
}

A supervisory or "audit" function is transformed to a two-track function by just passing Success and Failure inputs straight through to the outputs, and performing Actions on them along the way as needed.

lightw8 comment: You could imagine an enhancement to the Tee method to return a Failure (instead of void), if the action fails. But, then it's "just" an error-generating function (a good thing!), and we already have Bind for that. Speaking of which...

Exceptions

In this model the guidance is to "catch and don't release" exceptions that are relevant to this level of the computation, and return them instead as a formal Failure result. It's a judgement call about which exceptions to let propagate up the stack, but we should handle things that are reasonably in-scope. We don't want the code blowing up for things we have context for fixing/handling, but we also don't want to guess at the intent of the caller.

Validation, Events, Undo, Retries

Around minute 37 of the talk, Mr. Wlaschin talks about parallel validation logic, and this leads to a general discussion on how we can augment the Result structure to contain additional information on the success path, such as store/forward event data and allow for rollback/undo types of actions. Similarly, enhancing the error path can be used to enable retries in the case of errors. I won't elaborate further for now, but this might be interesting to revisit sometime in more detail.

Final thoughts

I enjoyed the challenge of creating these implementations without checking outside sources. So caveat emptor - no guarantees your trains will arrive on time with this code! In the next post, I'll work through a few examples of how we can use these functional building blocks in practice.

Thanks for reading, and talk soon. -David

¹ Concept and header image credit to Scott Wlaschin here

² C# type inference looks like it will be improving in C# 10, but for now, we need to explicitly specify the generic types when calling Bind<TIn, TOut>(...)

Sometimes a problem requires a simple "hack," or 1-off solution specific to the issue at hand. Sometimes, though, there's a characteristic of a solution that keeps recurring. Recognizing those patterns can be powerful, because they can be saved and re-applied to new problems in the future, or in a new domain. Practice noticing the "shape" of a problem-solution pair, then over time you accumulate these patterns in your toolbox for future use.

I just finished re-watching one of my favorite talks by Scott Wlaschin on a topic he coins "Railway Oriented Programming." It's a concise, funny and jargon-light view of patterns in functional programming (that's a lower-case "functional" by the way - while he uses some F# code, the patterns he describes are universal to all languages). He talks specifically about "Straying from the happy path," and how to deal with things that inevitably go wrong with software, without turning your code into a total mess. Per his web page fsharpforfunandprofit.com/rop, here's the blurb for the talk:

Many examples in functional programming assume that you are always on the “happy path”. But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances.

So, how do you handle all this in a clean functional way?

This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.

In the presentation, Mr. Wlaschin shows how originally-simple, linear, "green field" code gets turned inside out as we attempt to make it robust and "enterprise grade." Our ability to quickly understand and reason about the code plummets as different structures, branches and orchestrations are put in place to combat potential errors. The result is complex code that is very difficult to understand in terms of it's functional intent, and therefore difficult to maintain/modify/improve. This then quickly becomes "read-only" code that accumulates technical debt, and things ultimately grind to a halt. Traditional object-oriented approaches to wrangle some of this complexity - interfaces, proxies, factories, containers - tend to lead to yet more abstraction and still make things initially difficult to understand. It can be a lot of concepts to keep in your head all at once, and can often distract from communicating the intent of the code.

What's remarkable is how in the subsequent presentation he demonstrates that so many of these different challenges in modern software engineering - defensive programming, error checking, exception handling, coordinating async continuations, middleware audits, timeouts/retries - can be mapped to, addressed, and simplified using this simple railway mental model and a few functional-style helpers. The linear code that gets turned into a "Pyramid of Doom" of nested conditionals for catching potential errors, becomes re-linearized by putting the error handling pattern in the functional operators themselves.

The strategy is basically to adapt existing happy-path functions into two-output "tracks": the "happy path" for the code behaving correctly, and an "error path" for errors, exceptions, etc. Here's a quick example (Choice<T1, T2> is a "Discriminated Union" type...more on that later):

Choice<float, Error> MaybeInverse(float val) => val switch
{
    0f => new Error("Inverse!"),
    _  => (1 / val)
};

Then, using some simple helper building blocks (shh - they're monads, but I won't tell if you don't), you can stitch these individual components together into a pipeline, which will short circuit or accumulate the undesirable outcomes. He also shows the benefits of mapping errors and exceptions into meaningful domain-model entities that can be carried along with the normal data flow. These help the consumer of the code make more meaningful, reasoned use of the information, versus them having to deal with the multiple "early exit" possibilities that can explode in complexity as the application grows. At the end, he shows the original top-level naïve code next to the new robust error handling code: they're identical. The complexity is managed by the "glue" helper functions underneath, and the meaning/intent of the original code is preserved.

A great benefit of learning Mr. Wlaschin's railway track model is that along the way we also get one of the most accessible and understandable descriptions of functional programming constructs like monads and monoids. It was so clear that without much help, I was able to "follow along at home" and create some C# representations of the concepts and helper functions he describes. In the next post, I'll share some of that work.

Thanks for reading, and talk soon. David

P.S. As an aside, I'm starting this blog because I enjoyed this recent Hanselminutes podcast with Brian Douglas, in which Mr. Douglas mentions platforms like dev.to and hashnode, and encourages devs to avoid common blogging pitfalls and just get to the creating part. Thanks to him for the nudge.