DEV Community: Angelo Sciarra

IO: to be a Monad or not to be, that's the question!

Angelo Sciarra — Thu, 06 Aug 2020 13:55:30 +0000

Hello folks,
I promised you in How to live in a pure world I would have written a full article showing an example of how to deal with IO functionally and here it is!

I will use Kotlin and its functional companion library: Arrow.

A brief history of Arrow

Arrow was born as a merge of two functional libraries in the Kotlin universe: FunKtionale and Kategory. The contributors of the two libraries decided to join forces and so Arrow was born.

Like other libraries in other programming languages (like ScalaZ and Cats in Scala), Arrow tried to provide the same concepts of typed functional programming that were born in the Haskell universe: so they started out defining some core data types (Option, Try, Either, Validated, etc.) and a bunch of typeclasses like Functor, Semigroup, Monoid, Monad, and the likes (much more to be true).

The current version of Arrow is 0.11.0-SNAPSHOT. Arrow 0.11.0 should be released by September 2020, and the first major release should come out by the end of the year, even if it will not be marked as 1.0 but as 1.4, following the Kotlin compiler version (because of Arrow Meta).

What the team is working on to target the first stable release is to simplify and stabilize the api.

For example, they have already deprecated and they are going to remove the Try<A> data type, because it favors an eager evaluation of code that can have side effects, in favor of Either<E, A>. If you think about it you could say that:

typealias Try<A> = Either<Throwable, A>

and the non-eager evaluation is granted by the fact that, aside for right/left value constructors, the function Either.catch() you use to wrap throwing blocks accepts only a suspended block (more on this later).

The same kind of simplification occurred also for Option<A>. There were some questions in the Kotlin community towards the actual need for such a data type, given the Kotlin language features nullable types. So Arrow maintainers have decided to ditch the Option data type in favor of nullable types or, once again, Eithers, providing also easy means to go from nullable types to Eithers. Example:

val a: A? = null 
val b: Either<Unit, A> = Either.fromNullable(a)
// and if you like you can define  
typealias Option<A> = Either<Unit, A>

Monads

Before addressing the title question about whether or not IO should be modeled as a Monad, let's talk a bit about monads.

What is a Monad?

Last time I haven't spent much time on the subject because I wanted to focus more on the reason why IO operations were intrinsically impure

So, without further ado, here is maybe the most concise definition you could find about what a Monad is:

A monad is a monoid in the category of endofunctors.

The problem is this definition requires you to know what is a monoid, a category, and an endofunctor.

I'll try to provide you a short definition of all three.

Monoid

A monoid is a semigroup with a unit element, that respects the monoid laws. A semigroup is a set A with an internal operation, usually called combine, that is associative.

interface Semigroup<A> {
    fun combine(a: A, b: A): A
}

interface Monoid<A>: Semigroup<A> {
    val empty: A
}

The monoids laws are

associativity (because it's a semigroup): for all a,b,c in A it must be true that combine(a,combine(b,c)) = combine(combine(a,b),c)
left identity: for all a in A combine(empty,a) = a
right identity: for all a in A combine(a,empty) = a

Functor

What is a functor? It's a map between categories that preserves the category structure. To be more precise, given 2 categories C and D, F is a functor if

for every object X in C, it maps an F(X) in D
for every morphism f: A -> B in C it maps the morphism F(f) = F(A) -> F(B) in D
for every X in C it maps the identity morphism in C into the identity morphism in D, i.e. F(1xC) = 1F(X)D
for every two morphism in C, f and g, F(f . g) = F(f) . F(g)

An endofunctor is just a functor from a category C into C itself.

Given the previous parallelism drawn between a category and a programming language, you might be wondering: what is an endofunctor in a programming language?
Well, if you think about it, it should be something that maps its types (the objects) but also its functions (the morphisms) between the basic types (from the original category) into functions between the mapped types (in the new category, the one where all the objects have the form F<X>).

So an endofunctor F in Kc (the Kotlin types category) is a pair F = (F(X), lift) where

F(X) is a type constructor (i.e. F(X) is a new type in Kc)

lift is a function

    fun <A,B> lift(f:(A) -> B): F<A> -> F<B>

I guess all this might seem a bit abstract, so an example might help.

Ex.: Option<A> is a functor.

Why? Because it is a type constructor (from A to Option<A>) and it exist a lift function

    fun <A,B> lift(f:(A) -> B): Option<A> -> Option<B> = 
        { a: Option<A> -> a.map(f) }

Putting it all together

From all the definition above we can come back to a more operative definition of a monad: a monad is a type constructor with three functions

// pseudo code (to actually encode a generic monad one has to encode first the concept of higher kinded types)
interface Monad<A> {
    fun of(t: A): Monad<A> = // omitted
    fun <B> map(ma: Monad<A>, f: (A) -> B): Monad<B> = // omitted
    fun <B> flatMap(ma: Monad<A>, f: (A) -> Monad<B>): Monad<B> = // omitted
}

that obeys to the following laws

left identity: flatMap(of(x), f) = f(x)
right identity: flatMap(x, of) = x
associativity: flatMap(flatMap(ma, f), g) = flatMap(mx) {x -> flatMap(f(x), g) }

Note: the actual encoding in Arrow of Monads is a bit different, the above pseudo-code was made just to give a general idea.

IO monad

IO is a monad and in Arrow is undergoing the same simplification process shown above for the core data types: more specifically it's going to be deprecated and removed from the library (this time not in favor of Either).

The reasons in this case are different.

The first one is that Kotlin has a language feature (suspended functions and coroutines) that can better express the intent of a data type like IO<A>, with native support in the language.

Secondly, if you ever try to write actual programs using IO, you will probably end up with something like IO<Either<E, A>>, that is not so ergonomic to work with.

Let's see it with an example (finally, am I right?)

data class FileName(val path: String)
data class Employee(
  val lastName: String, 
  val firstName: String, 
  val birthDate: LocalDate, 
  val emailAddress: EmailAddress
)
data class EmailAddress(val value: String)

sealed class ProgramError
data class ReadFileError(val path: String): ProgramError()
data class ParseError(val source: String): ProgramError()
data class MailSendingError(
  val emailMessage: EmailMessage
): ProgramError()

typealias Program = 
    (FileName) -> IO<Either<ProgramError, Unit>>
typealias LoadEmployees = 
    (FileName) -> IO<Either<ProgramError, List<Employee>>>
typealias EmployeeFilter = (Employee) -> Boolean
typealias SendBirthdayGreetings = 
    (Employee) -> IO<Either<ProgramError, Unit>>

fun createSendGreetingsFunction(
    loadEmployees: LoadEmployees,
    employeeBornToday: EmployeeFilter,
    sendBirthDayGreetingMail: SendBirthdayGreetings
): Program = { sourceFile: FileName ->
    EitherT(loadEmployees(sourceFile)).flatMap { employees ->
        employees
            .filter(employeeBornToday)
            .map { e -> EitherT(sendBirthDayGreetingMail(e)) }
            .sequence().map { Unit }
    }.value().fix()
}

This is a snippet of code from my take on the birthday greetings kata by Matteo Vaccari (full code here, tag io-either-version-arrow-0.10.5).

The code per se is pretty straightforward: it will load a list of employees from a csv file, filter the employees born today and then send them a birthday greeting email.

To execute the program description built using IOs one need to do something like the following at the edge of his/her world (the main function, your rest controller, etc.)

val program = sendGreetingsToAll(FileName("/fixtures/bigFile.csv"))
program.unsafeRunSync()

NOTE: one common mistake one can make is to continuously create and run IOs. That is not the way (or it is not supposed to be). You should build your entire description of what your program does and then only run it once at the end of your world (so to speak).

The following are the functions in the previous snippet of code that have a side effect and have been modeled with IO

typealias LoadEmployees = 
    (FileName) -> IO<Either<ProgramError, List<Employee>>>
typealias SendBirthdayGreetings = 
    (Employee) -> IO<Either<ProgramError, Unit>>
typealias Program = 
    (FileName) -> IO<Either<ProgramError, Unit>>

What is the issue with them?
Well, it's something related to their composition.
Given that their return type is an Either nested inside an IO, working with it becomes a little cumbersome because, even if they are both Monads (IO and Either), and monads should make it easier to sequence transformations, having two nested monads you should first map or flatMap on the external one, IO, and then on the internal one, Either.

One would have hoped to be able to write

val f: (A) -> IO<Either, B> = // omitted
val a: IO<Either<E, A>> = // whatever
val b: IO<Either<E, B>> = a.flatMap(f)

But it's not possible. You have to write something like this

val f: (A) -> IO<Either, B> = // omitted
val ioA: IO<Either<E, A>> = // whatever
val ioB: IO<Either<E, B>> = 
    ioA.flatMap { eitherA: Either<E, A> -> 
        eitherA.fold(
            { e: E -> IO.just(e.left()) }, 
            { theActualA: A -> f(theActualA) }  
        )

That's the reason why you have seen in my previous snippet that EitherT. What is it? It is a Monad Transformer and let you compose two nested monads in case the inner one is an Either; in lemon terms, it's a data type that wraps the IO<Either<E, A>> and let you regain the easiness of sequencing operations.

Let's see how that would apply in the last example

val f: (A) -> IO<Either, B> = // omitted
val ioA: IO<Either<E, A>> = // whatever
val ioB: IO<Either<E, B>> = 
    EitherT(ioA).flatMap { theActualA: A -> 
        EitherT(f(theActualA)) 
    }.value().fix()

Monad transformers solve a problem, i.e. the fact that two Monads cannot be generically composed to produce another monad; the question is: is it the right problem to solve?
We have introduced IO to re-gain purity and referential transparency but it also adds already one wrapper layer around our impure logic; if, when we are using IO in real life, we end up having an IO<Either<E, A>>, and to work with it we have to use an EitherT, adding another extra layer with both a cognitive and performance overhead, one might ask: is it worth it?

Suspended functions

The answer is: maybe no. In Arrow 0.11.0-SNAPSHOT the maintainers decided to ditch the IO monad in favour of suspended functions. What does it mean? Let's have a look at the sendBirthdayGreetings example revised

typealias LoadEmployees = 
    suspend (FileName) -> Either<ProgramError, List<Employee>>
typealias EmployeeFilter = (Employee) -> Boolean
typealias SendBirthdayGreetings = 
    suspend (Employee) -> Either<ProgramError, Unit>
typealias SendGreetings = 
    suspend (FileName) -> Either<ProgramError, Unit>

fun createSendGreetingsFunction(
    loadEmployees: LoadEmployees,
    employeeBornToday: EmployeeFilter,
    sendBirthDayGreetingMail: SendBirthdayGreetings
): SendGreetings = { sourceFile: FileName ->
    loadEmployees(sourceFile).flatMap { employees ->
        employees
            .filter(employeeBornToday)
            .map { e -> sendBirthDayGreetingMail(e) }
            .sequence().map { Unit }
    }
}

Can you spot the difference? That's right here it is

typealias LoadEmployees = 
    suspend (FileName) -> Either<ProgramError, List<Employee>>
typealias SendBirthdayGreetings = 
    suspend (Employee) -> Either<ProgramError, Unit>
typealias SendGreetings = 
    suspend (FileName) -> Either<ProgramError, Unit>

All the functions that returned an IO<Either<ProgramError, A>> in the previous version, now simply return an Either<ProgramError, A> but are marked as suspend, signaling they need a safe environment to be executed (arrow-fx-coroutines provides such an environment).

So the suspend functions take the place of functions returning IO because they are, for all intent and purposes, delayed and conveying the same concept as the IO monad: something impure is going on.

Here is how you could run the previous function at the end of your world (in my case in the acceptance test)

import arrow.fx.coroutines.Environment

Environment().unsafeRunSync {
    sendGreetingsToAll(FileName("/fixtures/bigFile.csv"))
}

Easy, no?

Conclusion

IO: to be a Monad or not to be?

Arrow guys answer is: no, thank you. We have already a Kotlin construct that is more than enough to describe impure interactions with the external world: suspended functions.

What else? I don't know, I only hope to have given you a feel of how to use IO, monad, or not, in a real-life example.

References

Arrow docs
Bartosz Milewski category theory for programmers: videos, book
Giulio Canti functional programming notes (only for those of you who speak Italian and are versed in Typescript)
Scott Wlaschin visual explanation of the elevated world
A nice little post explaining functors, applicatives, monoids and monads in pictures

Domain modeling obsession

Angelo Sciarra — Sat, 25 Jul 2020 14:55:28 +0000

Hi there,
today's topic is "primitive obsession" and why it is important (to avoid it) in your domain modeling.

What is "primitive obsession"?

It is classified as a code smell and it signals the abuse of primitive data types to represent domain ideas.

Think of a class like this

data class CustomerInfo(
    val name: String, 
    val lastName: String, 
    val age: Int, 
    val email: String, 
    val address: String
)

What is wrong with it?

You could think that it is perfectly fine but give it a second thought: does your domain expert talk about Strings or rather Email Addresses?

Types are important in your design because they act as a live documentation of your domain model and rules.

Consider for example a validation process. I think you all perform some sort of validation of the data coming from the outside world into your domain.

Let's stick with the email example.

Suppose you have a function like

fun `throwing validate email`(toValidate: String): String = 
// omitted

fun validateEmail(toValidate: String): Validated<InvalidEmail, String> = 
// omitted

What is wrong with those two functions from a domain modeling point of view?

Well, what is wrong is that from a type point of view nothing is telling us that the validation process produced a valid Email Address.

Let's try to improve it.

inline class EmailAddress(val value: String)

val validateEmail: (String) -> Validated<InvalidEmail, EmailAddress> = 
// omitted

Much better now: we have a function that is perfectly sound also from a type point of view. It clearly states that it will take as input a String and will give back either an InvalidEmail error or an actual EmailAddress. (If you are curious about the Validated data type have a look here)

Why not being obsessed?

I know what may be critics about this way of designing your domain model: too much of a hassle!

And that may be even true for Java, where adding a class just to have a wrapper has a cost in terms of lines of code you have to maintain (if you think about it, it is a bit weird to have some penalties adding new classes in an OOP language where classes should be the bread and butter of your everyday programming!)

NOTE: with Java 14 there is the feature preview of Records that, even if intended to give an easy way of representing Value Objects, addresses also the problem of wrapper types (even if the ergonomics of records can be improved)

Other critics may be linked to performance penalties related to creating too many classes.

To answer to this line of criticism: performance, unless it is an outmost prerequisite of your domain (say you are designing a realtime engine or whatever), and even in that case, should be addressed later in the design process, i.e. when you have a design to test for performance, and only with the most analytical mindset: measure performances and then think about performance improvements and of course measure again to test your improvements actually worked.

NOTE The inline class, shown in the last code example, is an experimental feature of Kotlin, starting from version 1.3. It is designed to reduce the overhead of actually creating real classes and objects at runtime by replacing any instance of the class with the wrapped value. So it is an optimization to let you use wrapper classes to better express your business domain while not having to pay any penalty at runtime.

Why should you be obsessed?

Should you stop being obsessed at avoiding primitive obsession? No! You should go ALL IN and start modeling to be the more specific you can be at the type level. Consider for example you are modeling an order taking system: your order has a lifecycle and passes through different states. How would you go and model it?

A first try could be

enum class OrderStatus {
    PLACED, CONFIRMED, CANCELLED, ... // etc
}

data class Order(
    val id: OrderId, 
    val items: List<OrderItem>, 
    ...
    val status: OrderStatus, 
    ....
)

What do you think? Is it a sound design? Would it be easy to design functions that target a specific order status? Well, no. It would be much easier if you design the entire order as a choice type (or sum type in some circles)

sealed class Order(val id: OrderId, ...)
data class PlacedOrder(override val id: OrderId, ...): Order(id,...)
data class ConfirmedOrder(override val id: OrderId, ...): Order(id,...), 
...

With this kind of design, it becomes much easier to define functions that accept orders in a certain state because the order status is encoded in the different choices.

Ex.:

fun sendConfirmationMail(order: ConfirmedOrder) = // omitted

Conclusion

What do you gain from being obsessed with avoiding primitive obsession? Well, you gain a codebase that speaks your domain expert language (the so-called Ubiquitous language from DDD circles) and that is less prone to error because you always know what you are dealing with at type level.

DISCLAIMER: most of the concepts expressed in this article summarize, from my point of view, notions and ideas taken from two books you should read if you have not yet:
- "Domain Modeling Made Functional" by Scott Wlaschin
- "Refactoring: Improving the Design of Existing Code" by Martin Fowler

How to live in a pure world

Angelo Sciarra — Wed, 15 Jul 2020 07:18:46 +0000

Hello folks,
here I am with a follow-up of the previous article A matter of purity

In it I talked about what is a pure function and why should you even care.

I can imagine some questions may have arisen while reading it:

how to make partial functions total?
how to make pure and referentially transparent functions that perform some sort of side effect (like IO)?

Let's address these issues one at a time.

Make partial functions total

Just to get everybody on the same page let me recall what a partial function is:

given f: A -> B f is partial if it is not defined for all a in A.

How can one work on f to get an f' such that f' is total?

Well, there are 2 paths one can take:

restrict f domain A to those elements where f is defined, i.e.

f': A' -> B where A' is made of all a in A such that it exists a b in B where b = f(a)

Thinking about f as a function we can write in Kotlin or Java this path seems a bit tortuous;
augment B with a synthetic value that maps all a in A where f is not defined

f': A -> B' where B' is B union { epsilon } and for all a in A where f is not defined then epsilon = f'(a)

This second approach is the one we can pursue in our code using data types like Option and Either because when we say that our function
```
val f: (A) -> Option<B>
```
what we are saying is exactly that whenever we cannot return Some(a) we will return None. (Same goes for Either, whenever we cannot return Right(a) we will return Left(error)).

So that should give an answer about totality.

Make side effects pure

Once we have made our functions total, have we made them pure?

What about functions performing IO?

Let's see an example

fun readFileLines(path: String): List<String> = 
    File(path).readLines()

We know that this function may throw an IOException so, from what we said above about making partial functions total, we could turn it into

fun readFileLines(path: String): Either<IOException, List<String>> =
    try {
        File(path).readLines().right()
    } catch (e: IOException) {
        e.left()
    }

Now the function is total (you can argue that returning IOException as the error type may not be the best design choice, but we'll leave it like that for the time being).

But is it pure? Is it true that:

given the same path input it will always return the same Either value, be it a Right value or a Left one?

The answer is no because anytime we call this function we are interacting with the external world and we have no control or knowledge of what this world may look like at any time.

In the functional universe (well, to be precise, in the Haskell orbiting part) there is an abstraction meant exactly to describe this interaction. Let me introduce you the

IO (monad)!

Leaving aside the scary m-word, let's focus on the IO abstraction.

The idea behind it is simple: given that the interaction with the external world is not predictable, we are going to work with a type that is designed like:

data class IO<A>(run: () -> A) {

    fun map<B>(f: (A) -> B): IO<B> = // omitted

    fun flatMap<B>(f: (A) -> IO<B>): IO<B> = // omitted

    [...]
}

Can you see it? All that matters is that () -> A.

Why?

Because it is as if you are saying: provided that I promise to give you an A, you can transform it via map, if your transformation is a pure function, or via flatMap, if your transformation has again some kind of interaction with the external world.

We have transformed the real, unpredictable interaction with the external world with a description of it, simply introducing a delay. What we gained by doing so is that this description is once again a value, and we can play around with values freely.

NOTE: Kotlin has a construct built in the language, suspended functions, that can be thought a bit as our delay function (() -> A). For that reason, the creators and maintainers of Arrow (the functional companion for Kotlin) have decided to redesign their implementation of the IO data type to exploit suspended functions (and coroutines). I promise I will make an article dedicated to it, as soon as I manage to fully understand it myself :D

Conclusion

Is it easy to live in a pure world?

That is not really for me to tell you, only you can judge if what you gain is worth the pain (if you want to call it so). Nonetheless, I think that expanding your horizons and knowing about what it means to live in a pure world will provide you with a new perspective on how to interact with the world that can be useful also if you choose to remain in an impure world.

I hope to have given you some explanations of concepts you may have heard of but never managed to wrap your head around.

Well folks, what else to add?

To infinity and beyond!

A matter of purity

Angelo Sciarra — Thu, 09 Jul 2020 19:06:22 +0000

Hello folks,
for my second post I've chosen a more philosophical topic: pure functions.

I ended my first article talking about the concept of functions in FP, saying that:

functions in FP are just mapping between inputs and outputs (and nothing more)

This is an informal definition of pure functions.

Other definitions you may have heard are:

pure functions are functions in the mathematical sense
pure functions are functions that will return the same output anytime they are given the same input
pure functions are functions without side effects

The mathematical definition of a function is the following:

Given two non-empty sets X and Y, a function f from X to Y is a relation such that for all x in X there exists only one y in Y such that (x, y) belongs to f, or, said otherwise, such that y = f (x)

(note the for all is crucial because what we are looking for are total functions)

So, why should you care about pure functions?

Well, the reason is that the use of pure functions will help you write correct programs.

How? (you might be wondering)

Let's see.

Local reasoning

You may have heard about local reasoning or not. What it refers to is the ability to reason about what a piece of code does in isolation, meaning you don't need any knowledge about the context in which said piece of code is executed to understand what it does.

How pure functions relate to local reasoning? Well, if a function takes care only of transforming an input value in an output one, without relying on any other external piece of information, that function enables of course local reasoning about what it is doing.

Let's look at an example of a function that does not allow local reasoning

var counter = 1; 

fun `not easy to reason about`(anInt: Int) =
    if (counter < 5) {
        counter = counter + 1
        anInt * 2
    } else {
        counter = counter + 1
        anInt * 3
    }
}

Why is that? Of course, because the logic of the function relies on the mutable, global counter variable.

The same example can be translated into a more familiar setting for those of you who are more accustomed to Java and OOP (instead of Kotlin)

public class TheOne {

    private int counter = 0;

    public notEasyToReasonAbout(int anInt) {
        int result;     
        if (counter < 5) {
            result = anInt * 2;
        } else {
            result = anInt * 3;
        }
        counter = counter + 1;

        return result;
    }

}

I guess you have seen many classes like TheOne shown here.

What is the problem? Again the fact the method notEasyToReasonAbout is relying on the value of the mutable counter that is out of its scope (this time is not global but still has a lifespan that goes beyond that of the method execution and it can mutate over it).

DISCLAIMER

Am I saying that the OOP way of doing things is intrinsically impure? Not at all.
It is just that languages like Java tend to make it easier to use constructs that work against local reasoning (like mutability) while others (think of modern languages like Kotlin, or Scala) choose to make it easier to use constructs that make it easier to apply local reasoning (examples are the val keyword that introduces immutable references, the default choice of immutable collections over mutable ones and so on).

Referential transparency

Once you start adopting pure functions in your codebase you gain another capability you were missing before, referential transparency. What is it about?

Say you have a piece of code like

val x = aFunction(y)

If aFunction is a pure function you gain the ability to safely replace any occurrence of aFunction(y), provided that y is immutable, with x, because x will always be the result of applying aFunction to y.

Have you ever heard of temporal coupling? Well if you use pure functions you can forget about it and move around your values as you please.

Question time

Do you think the following function is referentially transparent?

fun `read file lines`(path: String): List<String> = 
    File(path).readLines()

Answer

No. The reason is that anytime you call this function, even with the same path as input, you are not sure you will get the same results. Reasons may be

the file doesn't exist anymore (then you'll get an exception)
the file has been modified (so the content will differ)
the file permissions have been changed and you no longer have read permission (once again you'll get an exception)

You may be wondering how can one write pure functions that do things like IO but I won't talk about this topic right now (you will have to wait for a new article 😏).

Function composition

The beauty of pure functions is that you can compose them or, going the other way around, you can split a big function into pieces and then compose them together to obtain the initial function.

If you think about it, writing a program to solve a need can be abstracted to writing one big function that turns our program input in its outputs.

As usual, the approach one takes is: divide et impera! But what's the point of splitting a problem in subproblems if you cannot glue back the solutions to the subproblems into an overall solution?

With pure functions, function compositions is a matter of having matching types.
Given f: B -> C and g: A -> B, they can be composed to obtain h: A -> C, because the output type of g matches the input type of f, so h = f . g

Conclusion

Once you start using pure functions, you will start to think more and more in terms of types and of functions as mappings between types.

Your workflows/use cases (whatever you are calling them) will naturally emerge from the types of the functions you have developed to solve the smaller bits of your problem domain.

Follow the types!

You will end up doing TDD: Types Driven Development!

Unchecked vs checked exception (with FP glasses)

Angelo Sciarra — Mon, 29 Jun 2020 16:37:35 +0000

Hi all,
for my first post/article/whatever here, I have decided to talk about an old argument in the Java community: the dreaded Checked vs Unchecked exceptions.

For those of you who have never heard of this, here is a brief recap:

Checked Exceptions: when calling a method that throws a checked exception the compiler will force you to either handle it with a try-catch block or add it to the signature of your method
Unchecked Exception: they extend the RuntimeException class and if not handled simply bubble up in your calls stack.

The dispute on their usage has been controversial, with checked exceptions usually regarded as the black sheep.

Arguments against checked exception that you could have heard are:

Checked exceptions can be ignored by swallowing them, so what's the point of having them?

    try {
        // do stuff
    } catch (AnnoyingCheckedException e) {
        // do nothing
    }

Checked exceptions are easy to ignore by re-throwing them as RuntimeException instances, so what's the point of having them?

    try {
        // do stuff
    } catch (AnnoyingcheckedException e) {
        throw new RuntimeException(e);
    }

Checked exceptions result in multiple throws clause declarations.

The problem with checked exceptions is they encourage people to swallow important details (namely, the exception class). If you choose not to swallow that detail, then you have to keep adding throws declarations across your whole app.

As far as I can tell, in the Java world the following best practice has been established:

use checked exception for public API
use RuntimeExceptions for your internal modules.

The reason being that checked exceptions clutter your code (so avoid them inside your module) but document the external behaviour of your API.

The point I want to make here is that:

RuntimeExceptions are evil

If you feel offended by this argument you're free to stop reading and go out for a walk, they say it's really good for your health!

Why are they evil?

Well because whenever you're throwing a RuntimeException from one method you're telling a lie.

Which lie?

Say you have a method like:

    public Money from(BigDecimal amount, String currency) {
        if (amount.signum() < 0) {
            throw new ValidationException("whatever");
        }
        return new Money(amount, currency);
    }

This method is lying! It is telling its user it will return an instance of Money given a BigDecimal and a String, but it is not, or at least not always.

You may say: I can always document this behaviour with a test, but still that is a loose end.

Another example might be:

    interface Repository<T> {
        T save(T elem);
    }

You know from your experience that the save method might throw an exception, but you have been told not to use checked exceptions, so you are failing to document it.

Another couple of considerations:

given their ability to bubble up in the calls stack, RuntimeExceptions are nothing else than glorified GOTOs
methods that throw RuntimeExceptions are more difficult to reason about because you have to keep that information in the back of your mind
it is too easy not to acknowledge a RuntimeException has been thrown

Checked exceptions, on the other hand, by forcing you to handle them are more honest and they are actually telling you that the method you are calling returns 2 possible values:

a value of its return type
or a value of the checked exception type it throws

By now I guess you might be wondering where I left the FP glasses I mentioned in the title: here they come.

In the FP world (disclaimer: I am just at the beginning of my journey in this world) there is a type meant to be used to express exactly the choice between two types: Either<E, A> where:

A is the right type (got the hint?), i.e. the type you would have ideally returned
E is the type of the possible error that may occur

Aside from being exactly what you might have been looking for to explicitly state what your method returns, Either is also a monadic data type.
Without going into the rabbit hole of talking about Monads, let's say a monadic data type exposes 2 functions that make it easy to work with the right value once you get an Either into your hands.

The 2 methods are:

map that takes a function f: A -> B and will turn your Either<E, A> into an Either<E, B>
flatmap that takes a function f: A -> Either<E, B> and will still turn your Either<E, A> into an Either<E, B>

You might be familiar with this 2 new functions because the new Stream API (since java 8) or Optional (again starting from Java 8) support those 2 functions.

And you may appreciate how they promote a more declarative way of programming.

Either instead is not in the Java JDK but you can find it in (not an exhaustive list):

VAVR, a functional extension library for Java (https://www.vavr.io/)
Arrow, a functional companion library for Kotlin, but you can use it also in your Java code if you wish (https://arrow-kt.io/)
the Scala lang itself (https://www.scala-lang.org/).

Conclusion

The FP way of thinking about functions as mapping between inputs and outputs (and nothing more) brought me to the conclusion that you should always

Return a value from your function or not return it (maybe the parallel does not work here). There is no try!

Or, to put it not in Yoda's terms,

A function should be total and always return a value!

Well that's all folks.

Hope you have enjoyed it!

DEV Community: Angelo Sciarra

IO: to be a Monad or not to be, that's the question!

A brief history of Arrow

Monads

Monoid

Category

Functor

Putting it all together

IO monad

Suspended functions

Conclusion

References

Domain modeling obsession

Why not being obsessed?

Why should you be obsessed?

Conclusion

How to live in a pure world

Make partial functions total

Make side effects pure

Conclusion

A matter of purity

Local reasoning

DISCLAIMER

Referential transparency

Question time

Answer

Function composition

Conclusion

Unchecked vs checked exception (with FP glasses)

Conclusion