Run-time exceptions are not related to the programming paradigm chosen, but to the fact that whatever the language chosen, something can go wrong at run-time:

• In assembler, exception handling was usually properly hand-implemented via interupts.
• In C, people used <signal.h> with signal()/raise() or setjmp()/longjmp()
• Ada, which aimed for robustness in a military context, brought a proper exception handling long before it enabled object orientation.
• OOP languages promoted abstraction, and therefore brought proper exception handling from start, since it provides anabstraction for handling unexpected situation.

Something unexpected can also happen when using functional programming languages. Therefore, many come with functional exception handling (e.g. Erlang, Scala, F#) that usually are a kind of try some-expression but-if-it-goes-wrong other-expression.

In Elm, things can go wrong unexpectedly as well. Elm innovates somehow, and instead of raising an exception, returning a special value to indicate that there is an exceptional situation. So it's not that there are no exceptions, but exceptions are just caught and transformed into special data values. Expetion handling is hidden. The big advantage is that there is no longer to wonder whether to raise an exception or return an error code, a typical design dilemna in languages with exception handling.

Let's take the divide by 0: while many languages raise an exception, Elm just returns a special value (0 for the division and NaN for the modulo, if I understood well). The special value then propagates to the other expressions without never abruptly ending the thing. While it is very comfortable to get these things handled by default, in the end, it is not very different from the try some-expression but-if-it-goes-wrong other-expression.

Run-time exceptions are not related to the programming paradigm chosen, but to the fact that whatever the language chosen, something can go wrong at run-time:

• Exception handling emerged as a special control flow mechanism before OOP, and appeared in the context of structured programming in PL/1 in the 70s.

• Functional programming languages handle exception via the data flow and many functional programming language comme with constructs (e.g. Erlang, Scala, F#) like try some-expression but-if-it-goes-wrong other-expression.

Elm innovates somehow: instead of having to explicitly rely on some try/else it returns special values to indicate that there is an exceptional situation. So it's not that there are no exceptions handling, but the handling is by defaut: exceptions are just caught behind the scene and transformed into special data values. The big advantage is that there is no longer to wonder whether to raise an exception or return an error code, a typical design dilemma in languages with exception handling.

Let's take the divide by 0: while many languages raise an exception, Elm just returns a special value (0 for the division and NaN for the modulo, if I understood well). The special value then propagates to the other expressions without never abruptly ending anything. While it is very comfortable to get these things handled by default, in the end, it is not very different from the try some-expression but-if-it-goes-wrong other-expression because you cannot really use an expression resulting from a divide-by-zero to do something useful and sooner or later you have to check if the result was valid.