Exceptions?

Posted Sep 20, 2024 13:37 UTC (Fri) by LtWorf (subscriber, #124958)
In reply to: Exceptions? by tchernobog
Parent article: Best practices for error handling in kernel Rust

Making code readable is still a valuable thing today though.

to post comments

Exceptions?

Posted Sep 20, 2024 14:43 UTC (Fri) by ebee_matteo (guest, #165284) [Link] (5 responses)

Yes, of course. My view is that non-trivial code tends to be far *less* readable when using exceptions.

I sometimes get the feeling that people in favor of exceptions are just experienced developers in programming languages that use them, but have had limited exposures to other programming languages with alternative error handling facilities.

Exceptions?

Posted Sep 21, 2024 10:57 UTC (Sat) by LtWorf (subscriber, #124958) [Link]

I do Python but also C/C++. Recently some go as well.

Exceptions?

Posted Sep 21, 2024 14:39 UTC (Sat) by zorro (subscriber, #45643) [Link] (3 responses)

I think that depends on the application.

If I'm developing a web service that talks to a database, then there is nothing I can do with errors returned by the database, except log the error and return a failure message to the client. Any code devoted to propagating such errors up the call stack is just noise.

This is generally true for all errors that are caused by bugs or the non-availability of a critical resource without which the code cannot function. For some applications this is the vast majority of error cases, and (unchecked) exceptions work very well for them.

Exceptions?

Posted Sep 22, 2024 10:35 UTC (Sun) by farnz (subscriber, #17727) [Link] (2 responses)

My experience is that the ? operator Rust uses for this is a good compromise; you have to mark everything that can propagate an error, but it then just calmly propagates without issue.

Otherwise, I find that you eventually hit a case where you're struggling to debug a failure because a call used to be infallible and fully local, but as the system has evolved, someone has changed it to be fallible; the "ceremony" provided by the ? operator is sufficient to both make this a deliberate decision on someone's part (not a bad mistake that slips past review), and to prompt you into investigating why the "infallible" function fails.

Exceptions?

Posted Sep 22, 2024 12:46 UTC (Sun) by zorro (subscriber, #45643) [Link] (1 responses)

But isn't the point of the article that you are losing valuable debugging information when propagating errors using the ? operator?

With (C#) exceptions you can log a nice stacktrace as a starting point (and often even end point) for debugging.

What's present in a Rust error

Posted Sep 22, 2024 14:39 UTC (Sun) by farnz (subscriber, #17727) [Link]

Capturing a backtrace is a decision made at the time you convert from the called function's error type to your error type; you can capture a backtrace (and if you use thiserror to derive the std::error::Error trait for your type, it'll capture a backtrace when you put a field of type std::backtrace::Backtrace in your error type, and both eyre and anyhow capture backtraces for you), or you can decide that you're not capturing a backtrace, and avoid paying the cost of capturing a backtrace.

The article's point is that you need to think about exactly what you capture in the error type, and what you log at the point of error, in a Rust program; in kernel C, it's simple because the error is almost always a negative integer, and thus your only choice is to log at the point of error, but in kernel Rust, you have more options - and you need to think through what you're doing and get it right.