Hacker News Reader

Comment by 0127 | Hacker News Reader

IMO this is where languages like Rust shine. The design patterns built into the language for handling errors (Result) - force you to handle errors / function results with sentinels, null pointers, or errnos are so much more error prone than handling a Result<T,E> using a match statement.

crypt() returning `*` is insane especially since these kinds of sentinels are all over /etc/passwd

View on HN

I guess this is where the culture around rust shines. You can write crypt that returns a string in rust just fine, just like you can write crypt that returns a tagged union in C. Cultural differences and syntactic sugar change which version is idiomatic.

I suppose if people started writing lots of code that crashed on error in Rust some enterprising developer might improve the function to always return a non-error value and set it to ‘*’ in error cases.

The culture is downstream of the design IMO. In general, people write the API that is obvious. In C, returning a string is obvious, while defining a custom OptionalString type is high friction. In Rust, returning Option<String> is as easy and obvious as returning a String.

In a C function returning a string, two or three idioms are common for signalling an error.

One is to return NULL for errors.

Another is to make the string result a parameter and use a return code to signal error.

A third, less common but still out there, is an error parameter.

Failure to observe these is on the caller. Forcing the caller to consider the error is probably where rust shines.

But a good C programmer is thinking about these idioms when they encounter a function signature for the first time, or they write one.

All the standard Rust libs use results. The standard C libs use errno, return 0, return -1, return EOF, return nullptr, segfault, or of course UB. Other libs dream up things like returning "*". C++ has exceptions in some areas but not others, and if you turn them off, they're segfaults. I actually like C, at least more than C++, but the error handling is the worst part.

Sure, you could write deliberately bad code in Rust by unwrapping everything everywhere, but the point is that it is a distinct choice to do so. You can’t forget to handle errors - you have to make the choice to disregard them. If you forget to check for NULL in C it won’t complain and it’s dependent upon you to remember to do so.

Unwrapping everything isn't even bad, that's what most webservers will do

always has amazed me that there was so much hate for java checked exceptions where handling errors ought to be the norm.

In the vast majority of programs, errors and non-results are irrelevant at the call site. You want to program for the happy path and not wrap every single call with error checking code or `try/catch/finally`.

    h = file_open(path)
    data = file_read(h)
    file_close(h)
    return data

is the code you want to read. This essentially is:

    return file_open(path).success(h -> h, file_read(h)).success(h, data -> file_close(h); data)

A language with thoughtful error handling primitives will support such code.

> You want to program for the happy path

This is the root of a lot of the evil. Yes, humans want to program for the happy path. It is a lot more fun. However, that bias leads to so much lack of diligence to properly deal with the unhappy path.

Syntax is not going to solve logic errors. No amount of checked exceptions or forced unwrapping of a result will help with TOCTOU or any number of similar vulnerabilities in code.

You ideally want to attack the problem at two ends:

- make the syntax noise-free so you can see what is happening

- build primitives at the syscall and stdlib level for common footguns

You would still need to deal with domain-specific logic errors, but you have at least reduced the surface area exposed to casual attacks.

> This is the root of a lot of the evil

It is not. Being extremely restrictive in the happy path, throwing all over the place, but have generic error handling code at the top level (e.g. HTTP entry point) makes for some pretty robust, stable, easy to read software. Albeit it typically has somewhat rough user experience.

The thing is, that's a pretty good place to start. From there on, you can handle exceptions one by one, surgically, and make things nicer.

I keep hearing how diligent it is to handle errors at the call site, always by people who end up making services that either crash for preventable reasons or bury errors. Python is actually safer than Golang, and I don't mean with type hints.

People using exceptions want to handle the unhappy path, just usually not at the call site.

that is the same as saying the method throws IOException

It might throw one. There is a difference between documenting what exceptions can be thrown and forcing every consumer to handle them.

returning a non-success you either handle it or pass it up the chain, potentially with not a lot of information about what originally caused it. with an exception you can retain the full information about what happened by either rethrowing it, throwing your own exception with it embedded as the cause or declaring that you don't handle it by saying you can throw it.

I generally prefer exceptions to result codes. You can even use the mechanism to throw useful results across nested function calls.

I do prefer Maybe/Option/Either style returns in some cases though. Makes for a cleaner API.

So each method has its uses.

I also have this nuanced view. I am glad my hashmaps don't throw KeyNotFoundException.

Yeah, checked exceptions are weird. Almost everything has some way to fail. The exact type of exception is usually meaningless, more like there are a couple of broad categories analogous to HTTP 4xx vs 5xx, and even then you usually don't want to handle it right there.

IOException must be #1 on the list of most ignored exceptions. Like okay what am I supposed to do really I'm just trying to run a select against my db

Well, for example, if you had opened a file to put the data into, you might delete the file or restore from a backup. But even if the answer is nothing, bubbling it all the way up to main is not the wrong answer. The point isn't whether you can do something, it's whether someone can do something.

The question is _where_ the error needs to be handled. It's almost never directly at the call site. And then there's a few issues with checked exceptions and Java language things (RMI, closures, etc) which make checked exceptions cumbersome. An exception (checked or not) might be worse than sum types, but they're still a thousand times better then returning an error in-band.

> The question is _where_ the error needs to be handled. It's almost never directly at the call site.

Which is why exceptions in Java can bubble up the stack? You don't have to catch it in a particular method you can let it go to the caller of the method, and so on.

Checked exceptions must be handled or declared. You end up with everything saying it can throw several random things like IOException.

Rust and Go literally have you handle it at the call site by default and if you don't want to you have to pass it on.

Go doesn't require you to handle or pass an error upwards. You can call something that returns err and just ignore it, compiler won't care. The "if err != nil" thing is annoying too. Rust made the right compromise with !

Which (at least the way it was done in Go) is ignoring 20 years of experience in programming language design.

Better design breeds better habits. In Java, you can end up handling a DNS exception 20 layers up the stack, even if your call never actually triggers a DNS lookup, simply because some method deep in the call stack declares it as possible. The culture is to propagate or wrap exceptions rather than translate them into domain-specific errors near the source.

Rust makes handling and mapping `Result` locally more ergonomic, even though `?` makes propagation easy too. Rust, however, also makes it easy to lose the context during propagation and end up with useless `Error`.

I agree but I think was also because Java didn't have sum types (or still doesn't? years I haven't read Java) and rethrowing is super easy, while Rust kinda nudges you into the right direction (if you need to rethrow at all, think if you want to rethrow verbatim or wrap with a semantic error type).

Right idea at the wrong time.

yep, 90% ergonomics in my view. If it had its time again with modern ergonomics thing could look very different.

They were overused, but some actually make sense, such as the IOException and SQLException

The problem with them all always comes when the ever-steady march of abstractions, features, and edge cases results in one routine throwing the same two error classes but in different places, and how you handle them is different despite being the same wrapper. Add a thousand developers and several years of churn, and poof you get extremely complex bugs that result from errors seeming to come from one place, but actually coming from another.

Having been on the receiving end of debugging that a few times, I no longer mind the in-band error handling, although admittedly I'm inexperienced enough to be confident its better. Just for the random code I've had to read where I just need to know exactly how something I didn't write and will never read again works, and whether the error is handled and how, i love reading in-band error handling, even if I too dislike the way an error laden routine must be written. Over time I've come to appreciate elegance "in the large" as opposed to the code I see in any individual function.

I always thought the ideas was great, but type system was holding it back. If you could have expressed that your thrown exceptions are the same as some other method's (e.g. a method of a class given as a parameter), and some other classes, then it could have been a lot less annoying. Powerful, even! But Java did take its sweet time to get even type parameters.

I have written very little Java, though, so this is more of an armchair analyst position.

Amen, people saw the symptoms of "needs more syntactic sugar" and misinterpreted it into "rigorous error handling is bad".

The same way that layered code should react/wrap/translate when it comes to return types, it should do the same for thrown exceptions, and checked-exceptions helps you do that. They're both results of computation.

Unfortunately this is also an area where a Rust programmer would likely just reach for the platform libc, because you really want to be compatible with exactly how the platform is hashing passwords. Once you know about the inconsistency, you can make predictable wrappers around it, but platform legacy is gonna keep throwing these curveballs.

It seems it used to return NULL, but they changed it for "convenience"

How is this more convenient, being able to display it as text?

Yeah too bad your adult-diaper language can't even host itself on most of the architectures where musl is relevant.

Another Rust self-suck session rendered completely irrelevant. Again.

Reply on news.ycombinator.com