Stream: project-error-handling

Topic: Reading


view this post on Zulip Jane Lusby (Feb 19 2021 at 17:00):

@Sean Chen finally had a chance to read https://msirringhaus.github.io/Where-everything-went-wrong/

view this post on Zulip Jane Lusby (Feb 19 2021 at 17:01):

i think I'm going to do a blog post

view this post on Zulip Jane Lusby (Feb 19 2021 at 17:01):

to follow up your blog post and go into more details on the reporting stuff in particular

view this post on Zulip Jane Lusby (Feb 19 2021 at 18:24):

another article that mentions error handling: https://blog.kraken.com/post/7964/oxidizing-kraken/

view this post on Zulip Jane Lusby (Feb 19 2021 at 18:24):

only briefly though

view this post on Zulip Jane Lusby (Feb 19 2021 at 18:24):

Ideally, each fallible function would have its own error enum to precisely capture its errors and handle them, but in practice it is too verbose and leads to using the less precise Error trait or one enum per module. The language could support this better: there are several initiatives and macros exploring this.

view this post on Zulip oliver (Feb 20 2021 at 16:08):

@Jane Lusby did you get anything finalized?

view this post on Zulip Jane Lusby (Feb 20 2021 at 16:11):

For the blog post? Not yet

view this post on Zulip Jane Lusby (Feb 20 2021 at 16:11):

Ended up having too much to do yesterday

view this post on Zulip oliver (Feb 20 2021 at 17:17):

sure, let me know if you wanna collab on it

view this post on Zulip Jane Lusby (Feb 20 2021 at 17:58):

I'll send you the draft once I've got it finished

view this post on Zulip Jane Lusby (Feb 20 2021 at 17:58):

But I have a pretty good idea of what I want to say in the article

view this post on Zulip Jane Lusby (Feb 20 2021 at 17:58):

Blog post same thing whatever

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:10):

starting to work on the blog post now

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:10):

https://hackmd.io/@rust-libs/B1wYs2WGO is where I'm drafting it

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:10):

its still extremely rough and early

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:11):

but one thing that came to mind that is probably relevant to you @Sean Chen

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:11):

is that once we integrate the error trait with the panic runtime

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:12):

we will probably want to intentionally disallow runtime handling of error payloads

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:12):

the worry being that we don't want people using catch_unwind and downcast the dyn Error type and use it to actually propagate error types

view this post on Zulip Jane Lusby (Feb 23 2021 at 00:14):

probably worth surveying people who use that API and see what people do with the payload from catch_unwind if anything

view this post on Zulip Joshua Nelson (Feb 23 2021 at 01:25):

I expect you'll find it's used most at ABI boundaries, since unwinding between Rust and C is UB

view this post on Zulip Joshua Nelson (Feb 23 2021 at 01:26):

I use it at work to resume a panic after the C code returns: https://gitlab.com/YottaDB/Lang/YDBRust/-/blob/master/src/simple_api/mod.rs#L1403, https://gitlab.com/YottaDB/Lang/YDBRust/-/blob/master/src/simple_api/mod.rs#L1580

view this post on Zulip Thom Chiovoloni (Feb 23 2021 at 01:59):

An error would be nice, since as is you end up doing stuff like https://github.com/mozilla/ffi-support/blob/main/src/error.rs#L258-L269

view this post on Zulip Jane Lusby (Feb 23 2021 at 16:01):

@Joshua Nelson I guess I mean more specifically if anyone is doing anything with the payload after panicking other than re propagating it

view this post on Zulip Jane Lusby (Feb 23 2021 at 16:01):

Which it doesn't look like you are

view this post on Zulip Jane Lusby (Feb 23 2021 at 16:01):

Which is cool and perfect

view this post on Zulip Jane Lusby (Feb 23 2021 at 16:02):

And validates my theory that there's not really many good uses to the payload after a panic starts unwinding because it's already been reported

view this post on Zulip Cam Cope (Apr 19 2021 at 02:41):

This post helped me understand why you can't just have a function return Result<T, impl std::error::Error> https://fasterthanli.me/articles/whats-in-the-box

view this post on Zulip Cam Cope (Apr 19 2021 at 02:51):

Though it does make me wish the compiler could just... walk the stack of functions that are called and calculate the max size, or something. But I think you guys already have some plans in the works for more ergonomic error handling, and it's probably more elegant/feasible

view this post on Zulip Cam Cope (Apr 19 2021 at 02:52):

The article might be a good source to borrow from when documenting the mechanics and limitations of handling errors generically though

view this post on Zulip Jane Lusby (Apr 19 2021 at 18:13):

we don't have any specific changes yet in mind atm for improving ergonomics for defining error types, so proposals are definitely welcome. The one you've just described sounds similar to anon enums or some DST related ideas I've heard, but I don't think any of those ideas have had a successful RFC yet

view this post on Zulip Jane Lusby (Apr 19 2021 at 18:13):

and ty for linking that blog post, I'll be sure to check it out

view this post on Zulip Jane Lusby (Apr 19 2021 at 18:14):

and ill add it to the prior art issue for the book

view this post on Zulip Joshua Nelson (Apr 19 2021 at 18:20):

Jane Lusby said:

and ty for linking that blog post, I'll be sure to check it out

everything by amos is top-tier, highly recommend


Last updated: Jan 26 2022 at 14:02 UTC