Stream: project-error-handling

Topic: dyn error handling


view this post on Zulip Jane Lusby (Sep 21 2020 at 21:56):

what don't you love about it @Yoshua Wuyts ?

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 21:57):

We had to redefine a fair few things (like macros), and there's the pesky problem where this error doesn't implement Error (error containers vs proper errors)

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:57):

aah yea

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:58):

the reporters not being able to implement Error issue is lame :/

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 21:58):

Not sure if we could avoid the macros; we want to rewrite them to always take a status argument — but the container thing might be more widely applicable

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:58):

something something chalk fixes this

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 21:58):

Oh will it?

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:58):

maybeee

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 21:58):

That's good news!

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:58):

we might be able to use specialization to resolve the coherence issues

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:59):

remains to be seen if we'll be able to specialize From impls

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:59):

as for the macros thing

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 21:59):

Oh haha, "maybe chalk fixes this" — I've heard that before

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 21:59):

Oh haha, "maybe chalk fixes this" — I've heard that before

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 21:59):

Fingers crossed

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:59):

well, i guess first I should ask

view this post on Zulip Jane Lusby (Sep 21 2020 at 21:59):

you dont have anyhow exposed as part of your API right?

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:00):

_assuming its an internal detail_

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:00):

I believe we have a From impl, so technically yes

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:00):

unfortunate

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:00):

Or a from_anyhow method? Lemme check

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:00):

private trait impls would be nice for this exact problem

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:01):

Not sure I follow? Which problem?

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:02):

exposing anyhow as part of your API

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:02):

i guess thats not really the problem at hand

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:02):

(also can't find the conversion — maybe we don't have it after all! Though I really thought we did..)

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:02):

its this one https://docs.rs/http-types/2.4.0/http_types/struct.Error.html#impl-From%3CE%3E

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:02):

they both look like Error so its sneaky

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:02):

Yeah I was confused; didn't see how those related — but agree it'd be nice for other things for sure!

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:03):

Ah dang

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:04):

the macros issue might be kinda resolved by merging the stuff from eyre into anyhow but the way it solves it potentially introduces other problems

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:04):

the idea being that with a ReportHandler based on eyre in anyhow you could store the status code inside of the anyhow::Error instead of alongside it

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:04):

so then you'd be able to just directly export anyhow::Error as your error type and you wouldn't have to redefine errors

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:05):

the hickup being that they _have_ to use the error handler you define, which is installed globally via a set_hook fn, and if they dont you wouldn't have access to status codes

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:05):

What we want to enable people to write is:

ensure!(user.is_validated(), 403, "Authentication required);

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:05):

or if they want to use another reporting hook

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:05):

aah, yea that wouldn't be possible

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:05):

you'd need to write your own macro for that still

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:05):

Yeah, that's what I was thinking

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:06):

Though I'm quite intrigued by Eyre being able to carry metadata

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:06):

with the eyre changes you'd do something like

if !user.is_validated() {
    Err(format_err!("Authentication required").status_code(403)))?;
}

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:07):

That's quite nice!

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:07):

:D

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:08):

Btw, I'm not the right person to chat about this — but something we've seen come up a lot in Tide is downcasting

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:08):

Swift recently introduced typed catch which I thought was quite nice

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:08):

as in tide ends up needing to use downcast instead of match?

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:08):

Dunno, feel there might be something there

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:08):

this doesn't surprise me

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:09):

i think this is a property of a certain style of application framework

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:09):

tower has the same property

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:09):

which annoys me

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:09):

because it doesn't actually integrate well with eyre::Report

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:09):

well, if you use certain middlewear that is

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:09):

It seemed like a choice between boxing and downcasting vs threading even more generics — we chose the former

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:10):

yea i think thats the right choice personally

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:10):

imo downcasting as a form of reacting to errors is fine and good

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:10):

the biggest downside being you don't get an enumerated list of errors in the source code you can easily reference to figure out what you need to handle

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:10):

It doesn't seem particularly smooth yet tho — haven't thought too much about it, but I feel there is something that could be worth thinking about

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:10):

the upside being that you still never fail to handle errors because you always have to handle the case where its none of the types you downcast too

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:11):

i think there might be some room for language level support of matching against type erased objects

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:11):

tho probably initially macro level support

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:12):

the error crate has some prior art for this

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:12):

https://docs.rs/error/0.1.9/error/macro.match_error.html

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:12):

https://docs.rs/error/0.1.9/src/error/lib.rs.html#99-115

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:12):

im guessing this is much like the catch you mentioned being added to tide

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:12):

This is the Swift feature btw: "multi pattern catch clauses" https://github.com/apple/swift-evolution/blob/master/proposals/0276-multi-pattern-catch-clauses.md

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:12):

gonna check that out rn actually

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:13):

cool!

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:13):

[meta note: not sure if we're still on topic for this stream; we should probably fork this to a new one. No idea how to do that on mobile tho lmao]

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:13):

is the catch macro you mentioned merged?

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:13):

yea let me do that

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:13):

Which catch macro?

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:14):

Yoshua Wuyts said:

Swift recently introduced typed catch which I thought was quite nice

oh swift

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:14):

i thought you meant you added a macro for handling downcast and match in tide

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:14):

didn't read properly

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:19):

Okay so according to https://www.hackingwithswift.com/new-syntax-swift-2-error-handling-try-catch the catch clause syntax in Swift only applies for enum-style errors

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:21):

Doesn't seem to work for something like downcasting afaict; and even doubt it'd work for "container errors" in the std::io::{Error, ErrorKind} style

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:22):

why not?

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:22):

Still tho — this is pretty interesting and seems like it could be a direction if we ever get to stabilizing try clauses in Rust

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:22):

it seems like you could have something like

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:24):

downcast_match err {
    err @ std::io::Error => match err.kind() {
        // ...
    },
    err @ _ => eprintln!("Error: {:?}", err),
}

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:24):

you'd need two inputs for each match arm as I see it, the type being downcast too, and the pattern(s) that type is being matched against on a successful downcast

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:25):

extremely strawman syntax but hopefully it gets the idea across

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:26):

I see

view this post on Zulip Gus Wynn (Sep 21 2020 at 22:26):

Having language support for downcast matching would be phenomenal, where I work we have some common cases that end up with long verbose if let chains

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:29):

Oh what if there was a catch and a downcast catch. Getting to the inner ErrorKind could even be as short as:

Adapting the Swift syntax we could have:

try {
} downcast catch ErrorKind:: NonBlocking {
 }

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:29):

Big ol' straw man too

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:30):

as in tying the catch syntax to try blocks?

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:30):

seems like you'd run into issues around the fact that try blocks are about control flow ontop of Result but this proposed catch is for dynamic dispatch based on dyn Error / dyn Any

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:31):

Yeah, I guess I didn't spell that assumption out

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:32):

Both dynamic dispatch for dyn Error and static matching on Error enums

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:32):

Though there is definitely a lot to unpack

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:32):

yea

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:32):

my preference would be to not tie it to try blocks in any way

view this post on Zulip Gus Wynn (Sep 21 2020 at 22:32):

Yeah I was gonna say, downcast matching would be super nice to make other non-Error-handling dynamic typing cases better as well

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:33):

getting equivalent syntax would be pretty easy

try {
    // ...
}.map_err(|err| catch err {
    ErrorKind:: NonBlocking => {
    },
})

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:34):

Perhaps before we can talk about downcast-based error handling we should get a better sense for downcasting in general (and lang facilities for that), but also gather a list of all the ways people construct errors right now

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:34):

tho i think the error kind special cased syntax woulud also run into issues because theres no standardized interface to kinds based on the error kind pattern

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:35):

Because off the top of my head it's: boxed dyn errors, enums, one-off structs, structs wrapping enums — but may be missing some

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:35):

one last strawman syntax

try {
    // ...
}.map_err(|err| downcast err {
    std::io::Error if err.kind() == NonBlocking => { // ... },
    _ => { // ... },
})

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:36):

there's also error codes

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:36):

/me wants exception terminology to be a thing

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:36):

templated errors

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:36):

Yoshua Wuyts said:

/me wants exception terminology to be a thing

you're in for a rough road on that one I fear :sweat_smile:

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:36):

the community seems pretty biased against exception terminology in my experience

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:37):

Ha; perhaps I should rephrase — we should own up to the fact that were using exception terminology and embrace it in future designs

view this post on Zulip Yoshua Wuyts (Sep 21 2020 at 22:38):

(deleted)

view this post on Zulip Jane Lusby (Sep 21 2020 at 22:38):

(deleted)

view this post on Zulip Joshua Nelson (Sep 22 2020 at 00:39):

Jane Lusby said:

downcast_match err {
    err @ std::io::Error => match err.kind() {
        // ...
    },
    err @ _ => eprintln!("Error: {:?}", err),
}

cc @Khionu Sybiern who I think had an idea like this a while back

view this post on Zulip Joshua Nelson (Sep 22 2020 at 00:39):

different syntax though, I forget what it was

view this post on Zulip Jason Smith (Sep 22 2020 at 03:45):

What is "exceptions terminology?" Is that like supporting a keyword called "catch," or something different?

view this post on Zulip Jubilee (Sep 22 2020 at 04:53):

"throw"
"catch"

view this post on Zulip Yoshua Wuyts (Sep 22 2020 at 17:22):

"try" being the one we already use

view this post on Zulip oliver (Sep 22 2020 at 17:28):

I thought currently Jane is in favor of try personally but thinks it's unlikely
to gain support generally

view this post on Zulip Jane Lusby (Sep 22 2020 at 17:37):

oliver said:

I thought currently Jane is in favor of try personally but thinks it's unlikely
to gain support generally

try as in try blocks is almost certainly going to become part of the language, it's already available on nightly and seems to be on the near horizon, I was referring to the change in terminology, which right now is almost always sold as "not exceptions"

for example, here's a snippet from The Rust Programming Language's chapter on error handling

Most languages don’t distinguish between these two kinds of errors and handle both in the same way, using mechanisms such as exceptions. Rust doesn’t have exceptions.

emphasis mine

My personal opinion is that I'm very in favor of try blocks and I don't much care about whether or not we call recoverable ____s in rust errors or exceptions, but I feel that the ship has already sailed and that it is too late to embrace the idea that recoverable ___s in rust are exceptions. However, I would not object if the majority of the project group and libs team felt otherwise and decided to embrace exception terminology.

view this post on Zulip Jake Goulding (Sep 22 2020 at 17:42):

That gets into what do people expect from the term "exception". Underlying implementation details, keywords like throw, syntax around how it's described, etc.

view this post on Zulip Joshua Nelson (Sep 22 2020 at 17:51):

'exception' to me implies classes and unwinding

view this post on Zulip Joshua Nelson (Sep 22 2020 at 17:52):

which is not the case in rust, and I think calling them exceptions would get people confused with panics

view this post on Zulip oliver (Sep 22 2020 at 18:08):

Alright so the try pattern will become stable eventually what remains to
decide is whether or how error handling will be integrated. To what extent are
we restricted by this:
https://github.com/rust-lang/project-error-handling/blob/master/CHARTER.md#non-goals

view this post on Zulip Jake Goulding (Sep 22 2020 at 18:10):

will become stable eventually

There's no guarantee of that, AFAICT. Nothing's stable until it ships.

view this post on Zulip oliver (Sep 22 2020 at 18:11):

Jane Lusby said:
try as in try blocks is almost certainly going to become part of the language


view this post on Zulip Jane Lusby (Sep 22 2020 at 18:11):

@oliver pretty much completely. try blocks and the try trait are used to model control flow, specifically the propagation of fallibility, and they're a language level feature. We're a libs team group focused primarily on how those errors are represented, rather than how they're propagated.

view this post on Zulip Jane Lusby (Sep 22 2020 at 18:11):

@oliver that was me speculating, what @Jake Goulding said is correct, there is no guarantee

view this post on Zulip Jake Goulding (Sep 22 2020 at 18:12):

My feeling is that this group isn't going to make any specific decisions that change the language (esp. w.r.t try blocks). We can provide feedback to the appropriate language team about how well (or not) the current / proposed try blocks work in conjunction with current or recommended error handling patterns.

view this post on Zulip oliver (Sep 22 2020 at 18:13):

I see so we should consider the try pattern but not deliberate on exactly how
it will use error types

view this post on Zulip Jane Lusby (Sep 22 2020 at 18:14):

oliver said:

I see so we should consider the try pattern but not deliberate on exactly how
it will use error types

I think we should not concern ourselves with try blocks at all

view this post on Zulip Jake Goulding (Sep 22 2020 at 18:14):

As a single data point, I've found that try blocks kind of suck to use (to put a fine point on it :innocent:).

view this post on Zulip Jane Lusby (Sep 22 2020 at 18:14):

we should focus on how errors are represented, how those representations are implemented, how they interoperate, how they're reacted to and reported, etc

view this post on Zulip Jake Goulding (Sep 22 2020 at 18:15):

Jane Lusby said:

I think we should not concern ourselves with try blocks at all

I'd disagree, mostly because I think that try, as part of the language, should be considered as much as match or if let or ? in regards to errors.

view this post on Zulip oliver (Sep 22 2020 at 18:15):

Jake Goulding said:

As a single data point, I've found that try blocks kind of suck to use (to put a fine point on it :innocent:).

Agreed, it's always a pain knowing if one is catching the right thing

view this post on Zulip Jane Lusby (Sep 22 2020 at 18:15):

Jake Goulding said:

As a single data point, I've found that try blocks kind of suck to use (to put a fine point on it :innocent:).

lets hope the lang team fixes that :sweat_smile:

view this post on Zulip Jane Lusby (Sep 22 2020 at 18:16):

Jake Goulding said:

Jane Lusby said:

I think we should not concern ourselves with try blocks at all

I'd disagree, mostly because I think that try, as part of the language, should be considered as much as match or if let or ? in regards to errors.

I feel like try and ? are related but neither of those are related to match or if let, which I'd more closely relate to downcast and equality / comparison traits.

view this post on Zulip Jake Goulding (Sep 22 2020 at 18:17):

but since it's (a) unstable and (b) the lang team's area, _this_ team is at best a slightly-more-knowledgable participant to those discussions.

view this post on Zulip Jane Lusby (Sep 22 2020 at 18:18):

yea, I encourage participants in this project group to also participate in lang team discussions about try blocks and such, just know that we won't focus on that in our meetings or issues

view this post on Zulip oliver (Sep 22 2020 at 18:25):

Not to be overly pedantic but not be involved in managing design discussions
could be revised to read not be involved in discussions

view this post on Zulip Jane Lusby (Sep 22 2020 at 18:41):

i think I'd prefer to leave the wording as is, "not involved in managing design discussions" as in not tracking work with issues in our repo, not having zulip threads focused on it, and not having it on the agenda, but separately members can and are encouraged to be involved in those discussions under the management of the lang team.


Last updated: Jan 26 2022 at 13:46 UTC