Stream: project-error-handling

Topic: Globally Consistent Error Reporting


view this post on Zulip Jane Lusby (Oct 26 2020 at 19:13):

Okay so here's the issue where I've written up a bit of a summary

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:13):

https://github.com/rust-lang/project-error-handling/issues/10

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:14):

the problem is that we'd like to be able to have more consistent error reporting

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:14):

(kinda redundant)

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:14):

an example being

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:15):

if someone has an .unwrap() on a result with a type that impls Debug and Error

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:15):

right now it will print the debug format

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:15):

if that type happens to be something like anyhow::Error or eyre::Report its kinda okay, you at least print all the sources

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:15):

but then you end up printing two backtraces

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:15):

the one captured in the error reprter

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:15):

and the one captured by the panic reporter

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:16):

panic hook

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:16):

w/e you wanna call it

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:16):

if you unwrap something that merely impls Error

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:16):

its debug format is usually a derive format

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:16):

and very verbose

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:16):

and may not include its source error messages at all

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:17):

Ideally I'd like panics to be able to be more information about the types they're reporting on

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:18):

but I think we're pretty limited on how much we can do that

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:18):

so one suggestion in the past from dtolnay was to add a is_termination() flag to Debug

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:18):

that indicates that the debug fmt is being used for an error report before exiting the application

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:19):

this also helps resolve some issues with having to use the Debug format in eyre/anyhow

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:20):

It would be nice if the Debug fmt for Errors could see that this flag is set, and that it impls Error (somehow) and use a more consistent format

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:20):

I don't thikn this really solves the problems though

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:20):

first of all, I don't even think we could implement that

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:20):

since derives dont have access to type information

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:20):

second, that wouldn't be universally consistent

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:20):

each error would be defining its own error format

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:21):

I have two ideas atm that I think could work

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:21):

once is concrete but doesn't cover every edge case

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:21):

the other is extremely vague and half baked

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:21):

for the first plan: based somewhat on @Mara 's panic plan RFC

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:22):

we could add a panic_error helper, for creating panics for error types

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:22):

then

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:22):

if we could somehow specialize the unwrap/expect functions on Result / Option (how???)

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:22):

we could have unwrap() where E: Debug

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:22):

and unwrap where E: Debug + Any,

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:23):

and unwrap where E: Debug + Any + Error,

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:23):

we might not want to bother with the any bound though

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:23):

since that restricts non static errors

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:24):

this would at least catch the main panic locations

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:24):

and presumably the same specialization could easily be applied to the Termination impl on Result

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:25):

then panic handlers could be written to handle dyn Error types

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:25):

this doesn't help with eyre and anyhow

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:25):

also i dont think you can box a Debug + Any

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:25):

since thats a compound trait object

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:25):

so i feel like theres many reasons this plan isn't possible...

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:25):

The even more half baked plans

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:26):

if we added a new Report trait

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:26):

std::fmt::Report

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:26):

which is a specialized version of Debug

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:26):

so all Debug types impl Report by default with their debug impl

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:26):

then you can override that

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:27):

and this Report format had some sort of inverse formatting relationship

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:27):

there's some global Error Reporting Object

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:27):

that is somehow accessible via the Report api

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:27):

through its formatter or something

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:27):

and you could do something like

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:28):

fmter.reporter.fmt_error(&self)

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:28):

so you pass yourself as an error trait object to the global reporter

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:28):

and then there could maybe be default specialized impls for Error types

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:29):

so if you implement Debug and Error, then instead of forwarding to the Debug impl, it uses the blanket provided impl from std

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:29):

which just calls fmt_error via the global formatter

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:29):

then we switch unwrap and expect and all those panicing functions to use Report instead of Debug

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:29):

the more I think about it the less half baked this seems

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:30):

and it seems to have less technical hurdles than the alternative solution

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:31):

the formatter might not even need to be global

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:31):

it might be able to go back up to the type handling the formatting itself

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:31):

which could just be your panic hook

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:31):

_now I want to try to proof of concept this_

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:32):

This feels pretty similar to structured logging actually

view this post on Zulip Jane Lusby (Oct 26 2020 at 19:32):

and tracing::Value

view this post on Zulip Jeremiah Senkpiel (Oct 27 2020 at 00:26):

oof this is pretty long, will try to get to reading it tomorrow(?), got dragged into other things today

view this post on Zulip DPC (Oct 27 2020 at 00:42):

thought this was a poem

view this post on Zulip Jane Lusby (Oct 27 2020 at 00:42):

sorry about this

view this post on Zulip DPC (Oct 27 2020 at 00:42):

no worries

view this post on Zulip Jane Lusby (Oct 27 2020 at 00:42):

@Jeremiah Senkpiel if you prefer I can boil this down into a comment in the original github issue

view this post on Zulip Jane Lusby (Oct 27 2020 at 00:42):

a lot of the information in this thread is redundant

view this post on Zulip Jane Lusby (Oct 27 2020 at 00:42):

stuff I was thinking about but then thought better of later

view this post on Zulip Jeremiah Senkpiel (Oct 27 2020 at 01:37):

@Jane Lusby I think it would probably be helpful if you were able to condense it into a comment. :sweat_smile:

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:44):

will do

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 27 2020 at 01:49):

Jane, Replied to your email.

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:49):

yea, I saw. don't worry about the minutes, I'll grab them from @Ashley Mannix 's comment on the ehpg issue

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 27 2020 at 01:51):

For my info, was there more I needed to add? I thought I summed everything

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:51):

I think i might be confused

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:51):

it looked like from your reply you took the minutes from a previous meeting and just changed the date and put in the correct participants

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 27 2020 at 01:53):

:innocent: True plus the link to the minutes. Wasn't sure if I needed to add more to the md.

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:57):

yea, the minutes need to be of the meeting we had

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:57):

not a previous meeting

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:57):

but @Ashley Mannix already created minutes for the meeting

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:57):

so you don't need to add anything

view this post on Zulip Jane Lusby (Oct 27 2020 at 01:57):

I'll swap out the old minutes for the ones from this meeting

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 27 2020 at 01:59):

:+1: thanks

view this post on Zulip Jakub Duchniewicz (Oct 27 2020 at 07:36):

I will also look into it today :)

view this post on Zulip Jane Lusby (Nov 02 2020 at 18:39):

sorry it took so long

view this post on Zulip Jane Lusby (Nov 02 2020 at 18:39):

https://github.com/rust-lang/project-error-handling/issues/10#issuecomment-720652610

view this post on Zulip Jane Lusby (Nov 02 2020 at 18:39):

but here we go

view this post on Zulip Jane Lusby (Nov 02 2020 at 18:39):

I wrote up a shorter explanation of my idea

view this post on Zulip oliver (Nov 02 2020 at 19:13):

this looks great!

view this post on Zulip Jakub Duchniewicz (Nov 02 2020 at 20:25):

oh, thanks! Got bogged down in day-to-day work so did not add any sensible input to the discussion yet :)

view this post on Zulip Josh Triplett (Nov 03 2020 at 15:29):

@Jane Lusby Having two arguments to the Report trait's method feels like a workaround for existing behavior, but the kind that we have to live with for all time.

view this post on Zulip Josh Triplett (Nov 03 2020 at 15:30):

(Or a workaround for specialization not being stable yet.)

view this post on Zulip Josh Triplett (Nov 03 2020 at 15:30):

Either way, it feels like there ought to be some other way...

view this post on Zulip Josh Triplett (Nov 03 2020 at 15:31):

The idea of the Report trait does seem like the right answer, to specifically handle error reporting.

view this post on Zulip Josh Triplett (Nov 03 2020 at 15:32):

It seems like it wouldn't be unreasonable to require people to wrap a type in a new type and add their own Report impl, to change reporting, rather than dealing with Reporter. Unless I'm misunderstanding the rationale for the Reporter trait.

view this post on Zulip Josh Triplett (Nov 03 2020 at 15:33):

And then, if you don't need Reporter because of newtypes, you don't need to pass it to Report.

view this post on Zulip Jane Lusby (Nov 03 2020 at 15:41):

the reporter like eyre::Report would essentially be one of those new types that specializes in carrying extra context like backtraces, is optimized to be one frame on the stack, has helper fns for adding new errors to the chain, etc

view this post on Zulip Jane Lusby (Nov 03 2020 at 15:42):

so I think you'd still want reporters, but yea I think you've got the gist of it

view this post on Zulip Jakub Duchniewicz (Nov 07 2020 at 17:57):

I dug a little bit into the issue and related topics. The generic access API sounds exciting and (though not the simplest) will probably solve some crucial problems right now.

view this post on Zulip Jakub Duchniewicz (Nov 07 2020 at 18:00):

so, maybe rephrasing what Josh already said. Report will be a drop-in replacement for Debug (by default - with the global, predefined reporter)? and Reporter will give the specialization point for this reporting mechanism, right?

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:02):

reporter isn't the specialization point, assuming I'm not mixing up the terms

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:02):

reporter is the hook into the Formatter for general class errrors or panics

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:02):

so its how you say "format me using your rules, here's all my data"

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:03):

Report is the trait that either prints it using your own rules or asks the Reporter to print it for you

view this post on Zulip Jakub Duchniewicz (Nov 07 2020 at 18:03):

I probably miss a lot of details still, but I see it as adding a neat layer of indirection we can fill in quite easily (with our own formatting etc)

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:03):

yea

view this post on Zulip Jakub Duchniewicz (Nov 07 2020 at 18:03):

I probably misused the 'specialization point' nomenclature

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:03):

the thing im trying to figure out is how to manage access to the Reporter

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:04):

should it be global?

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:04):

right now eyre has the same thing in it

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:04):

theres a global hook for constructing them

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:04):

but then the errors carry around the reporter with them

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:04):

and use that to implement the Debug impl

view this post on Zulip Jakub Duchniewicz (Nov 07 2020 at 18:05):

what is the alternative?

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:05):

not sure

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:05):

but I see the current system as limiting

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:05):

adam recently brought up that Diagnostic in rustc is somewhat similar to this split plus the generic member access rfc

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:06):

and now I think we should aim to have any universal reporting mechanism be sufficient for rustc's needs

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:06):

but if we could get rustc using the Error trait and still getting high quality errors

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:06):

while having simple apps be able to just use something like eyre and not worry about it

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:06):

then I think we can be confident that it's the right approach

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:07):

the things I mostly worry about is accessing context with lifetimes

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:07):

like source maps

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:07):

in the reporter

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:07):

if it's global it has to be static

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:07):

which severely limits data we can access

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:07):

so part of me wants it to be a parameter passes in, but from where?

view this post on Zulip Jakub Duchniewicz (Nov 07 2020 at 18:16):

Registering reporters at the call site is probably not the best idea

view this post on Zulip Jakub Duchniewicz (Nov 07 2020 at 18:17):

How limiting is having a global reporter? Is it much of a hassle in eyre?

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:27):

I haven't seen any concrete cases where it's insufficient

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:27):

tho in libraries that wish to interact with it there's some breakdown

view this post on Zulip Jane Lusby (Nov 07 2020 at 18:28):

but part of me thinks that's usually because libraries should stick to their own Error types rather than interacting with a reporter, but I know of good arguments in favor of them as well

view this post on Zulip oliver (Nov 08 2020 at 17:03):

and is having libs maintain owned Error types the general outline we are
referring to when thinking about a universal reporting mechanism?

view this post on Zulip oliver (Nov 08 2020 at 17:04):

or is 'any' meant to be significantly different than that?

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:05):

not necessarily

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:06):

I think we can make those two goals independent

view this post on Zulip oliver (Nov 08 2020 at 17:06):

tho we don't have 'universal reporting mechanism' defined

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:06):

but I think reporting and dyn errors like anyhow should be designed with eachother in mind

view this post on Zulip oliver (Nov 08 2020 at 17:06):

yet

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:06):

yea

view this post on Zulip oliver (Nov 08 2020 at 17:11):

so we are going to ask users to wrap their own reporters but haven't thought
through exactly what's included in that and how the lifetimes work when crossing
contexts

view this post on Zulip oliver (Nov 08 2020 at 17:11):

or whatever 'accessing context' means in that respect

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:23):

I think we're still pretty far from users having to worry about stuff

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:24):

but ideally most ppl shouldn't have to interact with these features at all

view this post on Zulip oliver (Nov 08 2020 at 17:30):

what is our definition of 'accessing context' then?

view this post on Zulip oliver (Nov 08 2020 at 17:40):

I'm still confused about reporting types v. error kind patterns

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:47):

my definition for context is information about an error or the system it comes from that isn't itself an error message

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:47):

so if you're writing a parser, the error might describe how syntax was violated, and the actual code snippet the error comes from would be context

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:48):

and the problem is accessing the source map (context) from an error reporter

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:49):

the universal reporting proposal might blur the line a bit between reporting types and errors

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:49):

or maybe more cleanly separate them

view this post on Zulip Jane Lusby (Nov 08 2020 at 17:49):

(still organizing ideas in my head)

view this post on Zulip oliver (Nov 08 2020 at 17:50):

me too :smile:

view this post on Zulip Jacob Lifshay (Nov 08 2020 at 20:04):

What about having a global 'static Reporter as well as allowing scoped thread-local overrides, something like:

pub fn set_global_reporter(v: Box<dyn Reporter + Send + Sync + 'static>); // panics if old reporter currently borrowed, or we could use Arc
pub fn borrow_reporter<R>(f: impl FnOnce(&dyn Reporter + '_) -> R) -> R;
pub fn with_scoped_reporter<R>(reporter: &dyn Reporter + '_, f: impl FnOnce() -> R) -> R;

view this post on Zulip oliver (Nov 08 2020 at 23:02):

does that allow for concurrent reporters?

view this post on Zulip Jakub Duchniewicz (Nov 09 2020 at 08:20):

do you think scoped thread-local reporters would be useful? I can see some uses for it, but is that a good solution for current doubts?

view this post on Zulip oliver (Nov 09 2020 at 14:21):

a couple things: I don't know if that's been discussed specifically so it's
possible the point is out of scope tho we are meant to consider how
representations inter-operate as well as how they're reached, hypothesizing about
a concurrent state where some amount of context concerning the run-time is
important isn't too doubtful, I was largely thinking about the idea of
'accessing context' within the spirit of a 'universal reporting mechanism'
which was just mentioned prior to, do you have any thoughts about that?

view this post on Zulip Jakub Duchniewicz (Nov 09 2020 at 15:12):

Could you explain inter-operate?

view this post on Zulip Jakub Duchniewicz (Nov 09 2020 at 15:12):

meaning that we have different representations of the error trace and they can collide?

view this post on Zulip oliver (Nov 09 2020 at 15:15):

here: https://github.com/rust-lang/project-error-handling/issues/10

view this post on Zulip oliver (Nov 09 2020 at 15:17):

I think conceptually collision could be an issue if errors were being generated
in parallel though I'm lacking a concrete example of that

view this post on Zulip oliver (Nov 09 2020 at 15:19):

the way it is being presented now is such that reporters won't be registered at
the call site though I'm not clear if that encapsulates concurrency

view this post on Zulip oliver (Nov 09 2020 at 15:45):

like I think with a parent reporter the program would have to halt when a error
message is being generated from a sub-process

view this post on Zulip Jacob Lifshay (Nov 09 2020 at 16:16):

oliver said:

does that allow for concurrent reporters?

I think so, you can have a non-'static reporter be in scope on multiple threads at once if using something like rayon's scoped threads, all you need is to pass the same reporter to with_scoped_reporter on every thread. The reporter would need to use a Mutex (or other primitive) internally for any mutable state. Alternatively, the global reporter could be set for 'static reporters and that would apply program-wide (except where locally overridden by with_scoped_reporter).

view this post on Zulip Jacob Lifshay (Nov 09 2020 at 16:18):

rayon could probably be extended to automatically copy scoped reporters between threads if reporters are always Send + Sync

view this post on Zulip oliver (Nov 09 2020 at 16:34):

does that impact rayon in any way?

view this post on Zulip Jakub Duchniewicz (Nov 09 2020 at 18:36):

oliver said:

like I think with a parent reporter the program would have to halt when a error
message is being generated from a sub-process

I get you now, this seems like a relevant issue with global things

view this post on Zulip oliver (Nov 09 2020 at 18:43):

a bunch of spaghetti reporting info is rotten, so some of the work on pointer
metadata may enable us to capture ordering relevant data or something in
rayon perhaps

view this post on Zulip Jane Lusby (Nov 09 2020 at 18:45):

Jacob Lifshay said:

oliver said:

does that allow for concurrent reporters?

I think so, you can have a non-'static reporter be in scope on multiple threads at once if using something like rayon's scoped threads, all you need is to pass the same reporter to with_scoped_reporter on every thread. The reporter would need to use a Mutex (or other primitive) internally for any mutable state. Alternatively, the global reporter could be set for 'static reporters and that would apply program-wide (except where locally overridden by with_scoped_reporter).

the biggest hole I see with this approach is the "you need to pass the reporter to every thread" bit. One of the goals here is to make it more or less impossible to mess up and lose information in your error messages

view this post on Zulip Jane Lusby (Nov 09 2020 at 18:45):

the key thing being panicking on an E: Error type where it leaves out it's source errors

view this post on Zulip Jane Lusby (Nov 09 2020 at 18:45):

so if we can forget to setup a reporter in a certain context and get error reports that look different that would be bad

view this post on Zulip Jane Lusby (Nov 09 2020 at 18:45):

and violate the "universally consistent" goal

view this post on Zulip Jacob Lifshay (Nov 09 2020 at 19:57):

Well, then just set the global error reporter using a 'static reporter. That would automatically apply program-wide (except where overridden).

view this post on Zulip Jacob Lifshay (Nov 09 2020 at 20:02):

supporting global reporters with shorter lifetimes is possible, but the semantics of what to do are quite messy when the reporter's lifetime expires and you need to replace the global reporter with the previous reporter.


Last updated: Jan 26 2022 at 13:46 UTC