Hacker News Reader

Comment by bobogei81123 | Hacker News Reader

This is just AI trying to tell us how bad we designed our programming languages to be when exceptions can be thrown pretty much anywhere

View on HN

So you think java's checked exceptions are a better model? No opinion myself, but that way seems widely considered bad too.

Why do you need exceptions at all? They’re just a different return types in disguise…

Also, division by zero should return Inf

Or -Inf, depending on the sign of the zero, which might catch some programmers by surprise, but is of course the correct thing to do.

  a/0 =  Inf when a>0
  a/0 = -Inf when a<0
  a/0 =  NaN when a=0

No this doesn't work either

In the context of say a/-0.001, a/-0.00000001, a/-0.0000000001, a/<negative minimum epsilon for denormalized floating point>, a/0

Then a/0 is negative when a>0, and positive when a<0

Why not just to use IEEE 754?

> According to the IEEE 754 standard, floating-point division by zero is not an error but results in special values: positive infinity, negative infinity, or Not a Number (NaN). The specific result depends on the numerator

Because sometimes it's very wrong

Way back when during my EE course days, we had like a whole semester devoted to weird edge cases like this, and spent month on ieee754 (precision loss, Nan, divide by zero, etc)

When you took an ieee754 divide by zero value as gospel and put it in the context of a voltage divisor that is always negative or zero, getting a positive infinity value out of divide by zero was very wrong, in the sense of "flip the switch and oh shit there's the magic smoke". The solution was a custom divide function that would know the context, and yield negative infinity (or some placeholder value). It was a contrived example for EE lab, but the lesson was - sometimes the standard is wrong and you will cause problems if it's blindly followed.

Sometimes it's fine, but it depends on the domain

With IEEE 754 you can always explicitly check for edge cases.

But with exceptions you can’t use SIMD / vectorization.

Yea that's totally fair, you'd need to build it in as a first class behavior of your code, doesn't necessarily mean that exceptions is the right way to do it.

But IEEE 754 works as you described in your last comment. It doesn't take the numerator's sign. So what's wrong?

Can you give more context on your voltage math? Was the numerator sometimes negative? If the problem is that your divisor calculation sometimes resulted in positive zero, that doesn't sound like the standard being wrong without more info.

> But IEEE 754 works as you described in your last comment. It doesn't take the numerator's sign. So what's wrong?

The numerator was always positive. The denominator was always negative (negative voltage is a pretty common thing), except when it became zero. That led to surprising behavior.

Right the whole point of the exercise was that sometimes the standard is wrong for your specific problem at hand. We spent lecture after lecture going over exactly how ieee754 precision loss worked, and other edge cases, so we could know how to exactly follow the standard.

Then we had an example where the sudden sign flip from a/-0.00000000001 = <huge_negative_number> to a/0 = <positive_infinity> would cause big problems with a calculation. If you didn't explicitly handle the divide by zero case and do the "correct for domain, but not following ieee754 standard" way, then you'd fry a component.

It's been a long time so I don't remember the exact setup, just the higher level lesson of "don't blindly follow standards and assume you don't need to check edge cases (exception or otherwise) because the standard does things a certain way".

It's a good lesson in defensiveness! But if your value was always either less than zero or negative zero it would have done the right thing, both domain correct and standard correct. It's hard to say exactly why you got positive zero, but my bet is that it's more subtle than the standard doing something you can actually call "wrong".

Unchecked exceptions are more like a shutdown event, which can be intercepted at any point along the call stack, which is useful and not like a return type.

Why do you need the call stack at all?

Debugging. It's one of the most useful tools for narrowing down where an error is coming from and by far the biggest negative of Rust's Result-type error handling in my experience (panics can of course give a callstack but because of the value-based error being most commonly used this often is far away from the actual error).

(it is in principle possible to construct such a stack, potentially with more context, with a Result type, but I don't know of any way to do so that doesn't sacrifice a lot of performance because you're doing all the book-keeping even on caught errors where you don't use that information)

Call Stack isn't a zero-cost abstraction, it makes threads more heavy-weight than they should be.

If you only need it for debugging, then maybe better instrumentation and observability is the answer.

The instrumentation and observability are more heavyweight than the overhead of unwinding the stack which is already keeping track of the most important information (in most mainstream langauges, at least. And even if you don't have a contiguous stack there's usually still the same information around at the point an error is created, assuming that you have something like functions that are returning into other functions. Exceptions, as a model, basically allow the code that raises an error to determine where the error is going to be caught without unwinding and removing the information that lets you track from the top level to where the error was raised). It is still tradeoff, of course (returning errors is more expensive than success), but it's one in a much better place in practice than other options (as obvious by the fact that errors-as-values implementations rarely keep this information around, especially not by default)

What about division of zero by zero?

> division by zero should return Inf

Sometimes yes, sometimes no?

It's a domain specific answer, even ignoring the 0/0 case.

And also even ignoring the "which side of the limit are you coming from?" where "a" and/or "b" might be negative. (Is it positive infinity or negative infinity? The sign of "a" alone doesn't tell you the answer)

Because sometimes the question is like "how many things per box if there's N boxes"? Your answer isn't infinity, it's an invalid answer altogether.

The limit of 1/x or -1/x might be infinity (or negative infinity), and in some cases that might be what you want. But sometimes it's not.

> Why do you need exceptions at all? They’re just a different return types in disguise…

You don’t need exceptions, and they can be replaced by more intricate return types.

OTOH, for the intended use case for signalling conditions that most code directly calling a function does not expect and cannot do anything about, unchecked exceptions reduce code clutter (checked exceptions are isomorphic to "more intricate return types"), at the expense of making the potential error cases less visible.

Whether this tradeoff is a net benefit is somewhat subjective and, IMO, highly situational. but if (unchecked) exceptions are available, you can always convert any encountered in your code into return values by way of handlers (and conversely you can also do the opposite), whereas if they aren’t available, you have no choice.

Correct, but that's not how I think about systems.

Most problems stem from poor PL semantics[1] and badly designed stdlibs/APIs.

For exogenous errors, Let It Crash, and let the layer above deal with it, i.e., Erlang/OTP-style.

For endogenous errors, simply use control flow based on return values/types (or algebraic type systems with exhaustive type checking). For simple cases, something like Railway Oriented Programming.

---

1. division by zero in Julia:

  julia> 1 / 0
  Inf
  
  julia> 0 / 0
  NaN
  
  julia> -1 / 0
  -Inf

Division by zero is mathematically undefined. So two's complement integer division by zero is always undefined.

For floating point there is the interesting property that 0 is signed due to its signed magnitude representation. Mathematically 0 is not signed but in floating point signed magnitude representation, "+0" is equivalent to lim x->0+ x and "-0" is equivalent to lim x->0- x.

This is the only situation where a floating point division by "zero" makes mathematical sense, where a finite number divided by a signed zero will return a signed +/-Inf, and a 0/0 will return a NaN.

Why should 0/0 return a NaN instead of Inf? Because lim x->0 4x/x = 4, NOT Inf.

OK, but I think it's not up to the programming language designers to define mathematical properties of the operations on specific data types.

I think the most pragmatic solution is to have 2 tiers:

1. use existing standards (i.e. IEEE 754 for FP, de-facto standards for integers, like two's complement, Big-Endian, etc.)

2. fast, native format per each compute device, using different sub-types so you will not be able to mix them in the same expression

> So you think java's checked exceptions are a better model?

Checked Exceptions are a good concept which just needed more syntactic-sugar. (Like easily specifying that one kind of exception should be wrapped into another.) The badness is not in the logic but in the ecology, the ways that junior/lazy developers are incentivized to take horrible shortcuts.

Checked exceptions are fundamentally the same as managing the types of return-values... except the language doesn't permit the same horrible-shortcuts for people to abuse.

Meme reaction: http://imgur.com/iYE5nLA

_____

Prior discussion: https://news.ycombinator.com/item?id=42946597

Reply on news.ycombinator.com