The original purpose of defining it to be Nan/INF in floating point was exactly that. You'd do all the work and then check if it was Nan/INF at the end without having to check every intermediate result.

If you want to do all the work at the end, 'exceptions' do exactly that, too.

Throwing an exception in a function normally stops the rest of the work that function would do. That is not the case when using Inf and similar

    > const f = (x) => [x/2, x/0]
    undefined
    > f(10)
    [ 5, Infinity ]

I assert stopping immediately is much more practical. In many cases, you waste considerable amounts of processing power to reach a conclusion you often won't be able to use.

It depends on your use case.

Sure but what should be the default?

Rust and Haskell can solve this fairly well: both styles of dealing with errors are easily accessible.

Go solves this really badly.

As for specifically what to do about division: the right default depends on your application. Either way is defensible, and I would rather work on making it easy to pick either style in the language of your choice, than to worry too much about what the default should be.

That's a good point, sometimes this is what you want.

The problem is that if you forget to check you find out a month later or ten functions over.

> I don't want to handle errors after every division and division doesn't crash.

You can have one or the other.

You can't have both without the risk of nasal demons. Unless the result of the operation is business-safe to throw away.

That's why having the default / have both is an poor design choice by gleam and pony. Someone will reach for / and encounter demons. Afaict the other langs that do this are not intended for real world prod use. By default / should force the developer into either crashable or unwrap error return. If you want some sort of opt-in "logic-unsafe /", fine but call it something else like </> e.g.