Comments (4)
aye, that's exactly what i wanted. now everytime the app crashes, I will have a clear indication of where something went wrong even before i check the log files.
from color-eyre.
I'm not familiar with what "rfd" means in this context or how exactly that would be accomplished. My expectation though is that if you wanted to write to a error dialog you'd have some sort of adapter where you just write the content of the Report
to the dialog rather than having it somehow redirect to a dialog automatically when you print it.
As a strawman example, here's what I'd imagine doing this if I were writing an app using dialogs
let dialog = get_some_write_type_for_the_dialog();
write!(dialog, "Error: {:?}", my_report)?;
Panics on the other hand aren't as easy to redirect to a dialog. I believe we have some machinery for accessing the panic reporting logic itself rather than the panic hook, so you can actually change where you output to, so this should also be possible but I'd have to look into how.
So I guess generally I'm not opposed to this but I'd want to start with creating an example for how this would work, and my expectation is that we wouldn't need to do this as a feature, but if in the process of setting up the example we find that we would then I'm entirely on board with supporting that. I do think it's important that eyre
/color-eyre
serve gui use cases well.
from color-eyre.
rfd is the popular file dialog crate https://github.com/PolyMeilex/rfd . it is sort of like a port of https://github.com/mlabbe/nativefiledialog .
one of the main purpose of the library is to open file dialogs or show message boxes like a crash reporter. before using color_eyre, I used to simply set a panic handler like below
rfd::MessageDialog::new()
.set_title("App Crash")
.set_description(&format!("{}", &e)) // e is the panic load. its not much of a color_eyre::Report, but its something :D
.set_level(rfd::MessageLevel::Error)
.set_buttons(rfd::MessageButtons::Ok)
.show();
and the plan as that if the app panics, users could just send a screenshot or copy the text from the dialog box and come to discord or github issues complaining about it. having a report (which we have for cmdline right now) would be a huge help in narrowing down the issue.
for example, if we open a bunch of files over the lifecycle of an app, and we crash at some point, we could just check the trace to see which file was missing.
I wanted it to be behind a feature flag because it has a lot of dependencies (as it works on all platforms including browser/wasm).
from color-eyre.
Okay, so I wrote up an example of how I'd do this in #103, can you take a look at that and let me know if it fits your usecase?
When I run it I get this output:
I had to disable the color theme because the dialog box doesn't seem to support ansi color-codes but it should work fine otherwise.
from color-eyre.
Related Issues (20)
- How to access fields of a Report
- Attach Report's to an error via Section::error()
- Report creation takes a lock HOT 3
- Print a backtrace/spantrace to debug logs not to stderr HOT 1
- panic in tests (I used master) HOT 1
- Is there an easy way to make custom errors have equivalent report functions HOT 1
- show sections when panic macro is called HOT 1
- Output has few/no colors in Gnome Terminal
- should info! events be captured and printed as part of the SpanTrace? HOT 1
- Mechanism to add sections in hook callback
- Omit numbering of errors if there's only one HOT 2
- color-eyre uses the same inexplicable information order as standard backtraces HOT 1
- Automate synchronization between docs.rs and README.md
- Disable setting panic hook HOT 2
- Ergonomics: Full re-exports from `eyre`; export `color_eyre::eyre!` macro, rather than `eyre` crate HOT 2
- Add a config option to print panic output to stdout.
- First eyre::Result::Err variant is slow to construct if backtraces are enabled
- Construct a new `Handler` after already having created one / modify handler HOT 1
- Wrap types so we don't have to re-export `owo_colors` HOT 2
- New version of backtrace doesn't export `gimli-symbolize` anymore
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from color-eyre.