Two kinds of error • Hacker News Board

Re: Two kinds of error

#21

Post by MadnessASAP » Wed, Mar 04, 2026, 12:50 AM UTC

tantalor wrote: post #18

> Expected: user enters invalid data > Unexpected: function must be called with a non-empty string, and someone didn't These seem like the same thing, I don't get why they are treated differently.

They are different from both the users and developers perspective. A developer can't prevent a user from entering invalid data, they can however check for invalid data and inform the user as such.

A user can't prevent a programmer from calling a function with a non-empty string, a developer however can ensure the arguments are valid before calling a function.

In both cases there is something the developer can do. Only in the 1st case is their something the user can do, but only if the program informs them of the problem.

BUT! And this but is something that really gets up my butt. If a programmer spits out a thousand non-fatal errors that I can't do anything about, I'm likely to miss the one error I can do something about. So that's also an important distinction between these 2 cases.

Re: Two kinds of error

#22

Post by scuff3d » Wed, Mar 04, 2026, 6:40 AM UTC

"Expected errors should not throw, raise, or panic. Instead, they should return an error result."

Part of the problem is devs often can't tell the difference between an error and a negative result. For example, I worked in a code base once that threw errors when a database query came back empty. That's not an error, that's a result! Errors should be _exceptional_ cases, like the connection to the database dropped, or the user provided bad input making the query impossible.

Errors as happy path control flow also drive me nuts.

Re: Two kinds of error

#23

Post by jaen » Wed, Mar 04, 2026, 12:19 PM UTC

bonoboTP wrote: post #20

This is the same distinction and motivation that led to Java's checked exceptions vs RuntimeException. It seemed like a good idea to enforce at the language level to handle what the author calls "known" errors, but treat "unknown" ones more leniently. It led to a lot of boilerplate and as far as I know with hindsight it's seen as a bad design choice because the line is not so clear to draw. As a first-order approxima…

The problem was mostly Java, not the idea.

Java enforced a rigid (static) disjoint exception hierarchy (necessitating the boilerplate wrapping), no error inference, inability to parametrize over thrown exceptions etc. etc. Basically fired all the language design footguns due to lack of experience and foresight (understandable at that point in history).

I'm sure this can be done with an actually decent design, and Rust developers do seem to be innovating in this space with the various error handling crates.

Re: Two kinds of error

#24

Post by xigoi » Thu, Mar 05, 2026, 2:04 PM UTC

ciroduran wrote: post #19

I don't think that this simplification is useful. In the context of a user, crashing a program is a very disruptive process. Crash enough times, and a retail user might just ask for a refund, or move a corporate process to get rid of the program. Some errors won't happen with the same repro case, e.g. a memory leak, handling that is hard.

What if the programmer is the (only) user?