Stream: project-error-handling

Topic: Termination trait question


view this post on Zulip Gray Jack (Jan 18 2021 at 00:50):

I was wondering if there was something blocking the stabilization of the Termination trait. It was pointed to me that there is some rough edges and that this project is handling it. My question is: What are the rough edges?

view this post on Zulip scottmcm (Jan 18 2021 at 01:51):

One thing that could use some attention is https://doc.rust-lang.org/std/process/struct.ExitCode.html

I think that Termination's method being self -> ExitCode would be clearer than the -> i32 version, for example.

view this post on Zulip scottmcm (Jan 18 2021 at 01:54):

And it'd be a nice thing to stabilize anyway even if Termination still takes a while after -- right now one has to call process::exit(c) to return a code.

view this post on Zulip Gray Jack (Jan 18 2021 at 03:58):

But ExitCode design still undecided, right? The feature itself calls it placeholder, and there was mini-RFC in the internals forum, but looks like there was no consensus if that approach was the correct one

view this post on Zulip scottmcm (Jan 18 2021 at 05:38):

Yeah, that's what I mean by some attention. Would be good to have someone look at it and either make a case for what it should look like, or argue that it should just get deleted.

view this post on Zulip scottmcm (Jan 18 2021 at 05:39):

If it's not useful, then it's clearly not part of Termination :P

view this post on Zulip Jane Lusby (Jan 20 2021 at 21:15):

following up on this

view this post on Zulip Jane Lusby (Jan 20 2021 at 21:16):

@Jakub Duchniewicz has taken point on digging into concerns about ExitStatus and trying to finalize the Termination design

view this post on Zulip Jane Lusby (Jan 20 2021 at 21:16):

also @Jakub Duchniewicz , @Josh Triplett has said he'd be interested in providing input for this issue

view this post on Zulip Jane Lusby (Jan 20 2021 at 21:16):

so yall should get in touch

view this post on Zulip Josh Triplett (Jan 20 2021 at 22:17):

@Jane Lusby I'm curious about something that may overlap with some of the other work in project-error-handling. I remember there being a proposal on the table to allow errors to carry optional information like "HTTP error code" or potentially even "HTML error page", so that HTTP servers could use normal error handling and just provide an extra bit of information. That seems related to the idea of having Error carry a "process exit code".

view this post on Zulip Josh Triplett (Jan 20 2021 at 22:18):

In both cases, there's a reasonable default (internal server error, default failure exit code), but also a need for applications to use arbitrary values.

view this post on Zulip Jane Lusby (Jan 20 2021 at 22:21):

That's the generic member access rfc

view this post on Zulip Jane Lusby (Jan 20 2021 at 22:21):

And that's a good point

view this post on Zulip Jane Lusby (Jan 20 2021 at 22:21):

I think that might be a good way to tie termination to the error trait

view this post on Zulip Josh Triplett (Jan 20 2021 at 22:21):

Exactly.

view this post on Zulip Josh Triplett (Jan 20 2021 at 22:22):

I'd much rather have that mechanism than have to manually implement Termination, or have some special-case code to handle both errors and an exit code...

view this post on Zulip Josh Triplett (Jan 20 2021 at 22:24):

I'm not necessarily suggesting that it shouldn't be possible to impl Termination for other purposes, but a mechanism to supply an exit code via an Error/Result return would mean Termination itself might not need to be stable as soon.

view this post on Zulip Jane Lusby (Jan 21 2021 at 00:41):

oh interesting

view this post on Zulip scottmcm (Jan 21 2021 at 02:14):

Oh, like one could add fn exit_code(&self) -> ExitCode { ExitCode::FAILURE } to Error.

view this post on Zulip Jane Lusby (Jan 21 2021 at 02:14):

yea, though likely it would not get its own method

view this post on Zulip Jane Lusby (Jan 21 2021 at 02:15):

and would be called like error.context::<ExitCode>()

view this post on Zulip Jane Lusby (Jan 21 2021 at 02:15):

and it would be Option<ExitCode>

view this post on Zulip scottmcm (Jan 21 2021 at 02:16):

I guess the major problem for main() -> Result<,> doing that is that right now it only needs Debug.

view this post on Zulip Jane Lusby (Jan 21 2021 at 02:16):

specialization?

view this post on Zulip Jane Lusby (Jan 21 2021 at 02:16):

Error is strictly more specific so it should work I expect

view this post on Zulip scottmcm (Jan 21 2021 at 02:17):

Sure, though if we're going specialization it could work pretty much however -- even Into<ExitCode>.

view this post on Zulip Jakub Duchniewicz (Jan 21 2021 at 09:04):

oh I like the concept of getting generic errors via context

view this post on Zulip Jakub Duchniewicz (Feb 15 2021 at 18:19):

I think I should ask for more ideas concerning this issue. I did some research and concluded that it is still mostly unclear what are the precise steps to take with this stabilization.

view this post on Zulip Jakub Duchniewicz (Feb 15 2021 at 18:22):

As far as I saw, there is some groundwork done, and some impl's but the design is still mostly vague and unspecific. I talked with Jane and she agreed that we should fill in the missing details in design.

view this post on Zulip Jakub Duchniewicz (Feb 15 2021 at 18:26):

So far the design of the trait seems to be very simple and I don't know how much we would like to extend it

view this post on Zulip oliver (Feb 15 2021 at 18:56):

https://internals.rust-lang.org/t/termination-hook-for-handling-error-from-main-result-someerror/13780

view this post on Zulip oliver (Feb 15 2021 at 18:57):

do we have a solution for the case where main returns Result::Err?

view this post on Zulip Jakub Duchniewicz (Feb 15 2021 at 19:01):

All I thought would be reporting it and translating to error code if such translation is possible

view this post on Zulip oliver (Feb 15 2021 at 19:01):

what error code?

view this post on Zulip Jakub Duchniewicz (Feb 15 2021 at 19:02):

std::process::ExitCode

view this post on Zulip Charles Ellis O'Riley Jr. (Feb 15 2021 at 19:07):

Thanks

view this post on Zulip Charles Ellis O'Riley Jr. (Feb 15 2021 at 19:29):

I thought I was off that

view this post on Zulip Jane Lusby (Feb 15 2021 at 19:29):

charles i thikn you're replying in the wrong topic

view this post on Zulip Charles Ellis O'Riley Jr. (Feb 15 2021 at 19:30):

I think that would be best

view this post on Zulip Charles Ellis O'Riley Jr. (Feb 15 2021 at 19:36):

I was looking at the last one

view this post on Zulip Charles Ellis O'Riley Jr. (Feb 15 2021 at 19:36):

That is Create a diagram

view this post on Zulip Jakub Duchniewicz (Feb 15 2021 at 19:37):

still, wrong topic Charles


Last updated: Jan 26 2022 at 14:02 UTC