Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

msirringhaus.github.io

Post reply on HN
Print view View original

191–200 of 204 posts

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#191

Post by pjmlp »

MaxBarraclough wrote: post #190
pjmlp wrote: post #189

Earlier quoted context omitted.

EINTR and longjmp can also surprise you, even in middle of calls, yet C doesn't have any exceptions.

You're right that the C language has many weird and wonderful capabilities and footguns. How does that address Chen's point about exceptions being unmanageable?

His point doesn't stand in any programming language that doesn't enforce error checking, exceptions or not, you will be surprised at any possible execution point if you don't check error values from previous call.

At least with exceptions you get a "I told you so" if something does happen, and a defined way to force application termination if the error isn't properly handled.

Given the remarks on the C++ post, I assume he belongs to the /EH- side of pitch forks and torches, which actually goes against the C++ best practices at Microsoft, https://docs.microsoft.com/en-us/cpp/cpp/errors-and-exceptio..., which leaves a feeling of a kind of biased article in some way.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#192

Post by danhau »

zaphar wrote: post #156
masklinn wrote: post #141

Earlier quoted context omitted.

> So... exactly the same problem that Java's checked exceptions have? Well yes, but also no because Java's checked exceptions have issues which go way beyond that. Hell I'd say this is not an issue because of the other issues. In Rust the thrower decides whether the error must be handled, but the default is "yes", and it's the overwhelmingly common decision. Panic is the exception (or multiple APIs are provided). Rus…

Errors are a part of the API. I'm not sure why we keep thinking we need to treat them differently. We don't complain when we have make decisions based on or transform data that is passed to us from a function or method. We just handle the data. Errors are just more data. The correct thing here is to correctly model your Error domain and map errors you don't control to Errors that you do. In the Java Checked Exception…

Thank you. Couldn't agree more.

It seems programmers want errors to handle themselves. It's like they want errors to automagically hook themselves into the entire code base and do "the right thing". Or maybe in other words: programmers mistake errors-as-additional-data, with errors-as-automatic-runtime-behaviour.

Am I crazy?

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#193

Post by pferde »

nullc wrote: post #181
pferde wrote: post #55

Earlier quoted context omitted.

I prefer it when a program just gives up and crashes when it encounters an unexpected condition, instead of trying to soldier on and later possibly corrupting some data or state I care about, because it was working under incorrect assumptions. Now, the amount of unexpected conditions should be kept to a minimum, essentially just things outside of control of that program that the program cannot verify reliably. The re…

In C applications people will generally fprintf(stderr, "Froboz option requires a grimulax!\n");exit(EXIT_FAILURE); Which is pretty useful. In rust, my experience is that it's far more common to unwrap an empty result and just toss a panic which spams some almost completely inscrutable error at the user. I'm not sure what the cause is-- it's been suggested to me by a heavy duty rust user that part of it is norms for…

Sure, a library has to handle errors differently than an application using that library.

The library should "back off" by aborting anything it is doing and indicating failure without crashing or exiting the process (a return value indicating an error, setting the "errno" variable, making an error pointer provided by the caller point to an error object/struct, ...). Of course, the other side of the coin is that caller (the application or another library) has to actually check for that error indication, and determine what to do about it.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#194

Post by a1369209993 »

masklinn wrote: post #183
a1369209993 wrote: post #176

Earlier quoted context omitted.

In the cases where the problem is actually panicing (ie, a non-total function) rather than your choice of core-dumping code, lack of panic-ability is strictly insufficient - `while(1){/*busy-loop*/}` is exactly as bad as `panic();`, and what you actually need is not "must never panic", it's "must make forward progress within some (not necessarily rigorously defined but) small amount of time". That doesn't have anythi…

> lack of panic-ability is strictly insufficient Sure. It is also by far the largest risk you face, so would solve a good 4 or 5 nines if the issue. > And really, noreturn ought to be enough to infer that on its own. noreturn only works for functions which never return. Most panicking functions do return, just not all the time.

> noreturn only works for functions which never return. Most panicking functions do return, just not all the time.

Sorry, I meant that any function that was noreturn could be inferred to take up to forever to return (since it always takes forever to return, since it never returns). Then, any function that calls such a function (in a non-DCEed position) can be inferred to also take up to forever to return (even though it might take less than that), because some possible code path through it (it's up to X amount of time to return) takes forever due calling a function that takes forever.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#195

Post by folmar »

wizzwizz4 wrote: post #49
nwellnhof wrote: post #30

Earlier quoted context omitted.

> Rust error handling is great for reliable systems. Last time I checked, Rust couldn't even catch malloc failures.

To be fair, these days malloc doesn't fail ; your program crashes when it tries to use the memory, and there's nothing you can do about it. (But I agree that this is a problem with Rust's alloc system.)

It can, it just doesn't when the 0physical memory is exhausted, but there are other conditions

    $ ulimit  -v 10240
     nil

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#196

Post by masklinn »

a1369209993 wrote: post #194
masklinn wrote: post #183

Earlier quoted context omitted.

> lack of panic-ability is strictly insufficient Sure. It is also by far the largest risk you face, so would solve a good 4 or 5 nines if the issue. > And really, noreturn ought to be enough to infer that on its own. noreturn only works for functions which never return. Most panicking functions do return, just not all the time.

> noreturn only works for functions which never return. Most panicking functions do return, just not all the time. Sorry, I meant that any function that was noreturn could be inferred to take up to forever to return (since it always takes forever to return, since it never returns). Then, any function that calls such a function (in a non-DCEed position) can be inferred to also take up to forever to return (even though…

That is true, although I don't know how helpful that is aside from checking that the annotation is not broken? Much like `const`, the annotation would have to be opt-in either way:

* Rust doesn't infer function types (on purpose)

* like const (or Copy), the removal of the flag is a breaking change, so it should not happen implicitly

So functions would necessarily have to be explicitly marked as e.g. `convergent` or whatever. And while callers of `!`-functions would be easy to check for, I don't think rustc is currently smart enough to infer the totality loops in general.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#197

Post by a1369209993 »

masklinn wrote: post #196
a1369209993 wrote: post #194

Earlier quoted context omitted.

> noreturn only works for functions which never return. Most panicking functions do return, just not all the time. Sorry, I meant that any function that was noreturn could be inferred to take up to forever to return (since it always takes forever to return, since it never returns). Then, any function that calls such a function (in a non-DCEed position) can be inferred to also take up to forever to return (even though…

That is true, although I don't know how helpful that is aside from checking that the annotation is not broken? Much like `const`, the annotation would have to be opt-in either way: * Rust doesn't infer function types (on purpose) * like const (or Copy), the removal of the flag is a breaking change, so it should not happen implicitly So functions would necessarily have to be explicitly marked as e.g. `convergent` or w…

> Rust doesn't infer function types (on purpose)

> I don't think rustc is currently smart enough to infer the totality loops in general.

Well, yes; we're necessarily talking about changes to the language (or, equivalently, possible different languages).

> while callers of `!`-functions would be easy to check for, [other problems wouldn't]

That was my point, thanks: "when trying to save your crucial data to disk, in real-time code where panicking would maybe kill someone in the real world, etc", checking for the easy-to-check-for problems doesn't actually suffice to prevent disasters.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#198

Post by mlindner »

xxpor wrote: post #178
mlindner wrote: post #175

Earlier quoted context omitted.

So you want your kernel to panic whenever it runs out of memory?

Yes, for servers! Hard failures are much easier to deal with than soft-not-dead-but-still-useless states. echo 1 > proc/sys/vm/panic_on_oom

Interesting. The company I just left sells a load balancer/application server/do-everything-box and one of the rules of the coding is that it must never crash. Even out of memory errors need to be recovered from and we shut off the kernel feature that makes malloc not actually malloc memory.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#199

Post by zanellato19 »

ymbeld wrote: post #111
Kaze404 wrote: post #45

Earlier quoted context omitted.

Isn't that what the Result type on Rust is? Sure, one of the branches is still called Error but it's just a plain language construct (a sum type you can write yourself).

The Result type is specifically designed to store value-or-error. One may use it diffently but that’s what it’s made for. The library designers had a choice between making a generic this-or-that type or a value-or-error type and they chose the latter because they thought that that would be the common this-or-that use-case. Even Haskell’s more generic-sounding “Either” type is made for the same purpose: the “right” (a…

While Result is designed for that, it was built with an Enum (see here: https://doc.rust-lang.org/src/core/result.rs.html#241-251)

So you can also build an enum that doesn't have any explicit mention of which is the right path

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#200

Post by simiones »

sensitive-ears wrote: post #174
simiones wrote: post #78

Earlier quoted context omitted.

I'd love to when I get a chance. I did see that Rust seems to favor a ? macro that seems to make error codes behave essentially like exceptions, so I am curious to try it out at some point and see if that ends up being any different from exceptions in practice.

The "?" operator doesn't turn them into exceptions, it's just a "return-early-if-error" shortcut. The main difference being that the caller still has to handle the error of a function using "?". (even if it's by punting further up the call stack with more "?", which you could argue is exactly how exceptions work, but it is at least explicit in what functions can fail and which don't)

> even if it's by punting further up the call stack with more "?"

Yes, this is exactly what I meant.

> it is at least explicit in what functions can fail and which don't

So is Java with exceptions (at least as long as developers are even slightly disciplined).

Post reply on HN