~icefox/garnet#19: 
Figure out (basic) errors/panics

Basically, how do we signal something went wrong when an integer overflow happens or some other assertion fails?

Status
REPORTED
Submitter
~icefox
Assigned to
No-one
Submitted
3 years ago
Updated
8 months ago
Labels
T-TODO

~icefox 3 years ago*

Simple choice: Exit program without running destructors. This means we will leave file handles, network sockets etc. in bad states though. Rust's panic='abort', basically.

Next choice: Run destructors on main thread, then exit program. This just leaves other threads hanging though. Probably not worth considering.

That leads to doing what Rust does: Run destructors and exit thread. Other threads can watch for it, pull the panic value out of the thread's handle, etc. That gets complicated, aieeeeee. Might be worth thinking about more; what if "panic in thread" works differently from "panic in main thread?" You can pass arbitrary code into a thread though. I dunno!

Either way we can't always promise to run destructors, but it's pretty nice to always run them when we can.

Panicking across FFI boundaries, as always, gets wacky. It would be nice for a function to be able to assert that it does not panic though, now that I think of it...

~icefox 1 year, 11 months ago*

Interesting conversation and design stuff in this article: https://lobste.rs/s/8mqgal/different_ways_handle_errors_c

~icefox 1 year, 2 months ago

Zig has some interesting approaches on handling error traces and unwinding: https://ziglang.org/documentation/0.10.1/#Errors

~icefox 1 year, 1 month ago

~akavel 8 months ago*

Isn't it expected that the OS will clean up any handles after a crashed application?

Also: https://lwn.net/Articles/191059/ ("Crash-only software...")

As to Zig's errors, they have one long-standing unresolved ticket that for now is mostly being kept swept under the rug: https://github.com/ziglang/zig/issues/2647 (see e.g.: https://github.com/ziglang/zig/issues/2647#issuecomment-1444790576)

And now it also reminds me that Araq (Nim creator) has some blogpost musings about error handling: https://nim-lang.org/araq/quirky_exceptions.html

~icefox 8 months ago

Isn't it expected that the OS will clean up any handles after a crashed application?

It will, but... hmmm, things like databases are the things that generally want to Really Maintain Consistency even in the face of errors, but they tend to do it not by cleaning up when an error occurs, but by structuring the data in such a way that it's guaranteed to be recoverable no matter when an error happens. Journals to be replayed, detection of partial writes, etc.

So it's worth considering what kinds of things can and/or should be reasonable to guarantee in the face of an error. The main concerns for the language itself, rather than an application, are things that maintain internal consistency. Allocator state/memory leaks for example, or unlocking mutexes.

Register here or Log in to comment, or comment via email.