Follow

As a programmer, when you call a function (or procedure or method or other piece of code), you should always check that it succeeded and if not, handle the error.

This is easy to get wrong.

A quality of a programming language is how easy it is to overlook handling of an error.

Good: Rust Result values; Python exceptions.

Bad: Unix system call integer codes; C functions that return NULL for error; shell scripts that invoke commands that can fail.

(Any command can fail.)

@liw Yes, Rust's result/Error system is very neat, and although perhaps not intuitive at first,, the way that it chains together with else/or/and's in various places is very flexible.

@penguin42 @liw The tool that makes the difference between a normal value for Rust's Result values is the unused_must_use warning that is enabled by default. Maybe having something like this in C would be nice, but it would be much more difficult to implement in a compiler because of all the different ways errors might be signalled.

@liw I just love how #Scala does this with Either.. scala-exercises.org/fp_in_scal

Too bad I mainly work with #TypeScript and nothing as fancy as this is readily available.

@nemeciii @liw There's Purify library which I've used a little. Good option if you can't go full on FP. gigobyte.github.io/purify/

@nikoheikkila @liw this looks promising, thanks.

FP-TS has apparently progressed a lot since last spring when I last checked.
gcanti.github.io/fp-ts/

Sign in to participate in the conversation
toot.liw.fi

Lars and friends