Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show more errors #1967

Merged
merged 2 commits into from
Oct 10, 2020
Merged

Show more errors #1967

merged 2 commits into from
Oct 10, 2020

Conversation

Hocuri
Copy link
Collaborator

@Hocuri Hocuri commented Oct 4, 2020

Examining deltachat/deltachat-android#1631 I realized that the current warnings are not very helpful.

Copy link
Member

@flub flub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sketched some more how I think we would be ideally handling errors and which direction it's best to move in. I appreciate it may be hard to do however and am not objecting to this as an intermediate step to improve error reported right now. But if you're working on improving errors I think it's good to look at the big picture as well.

@@ -574,7 +574,7 @@ pub enum Error {
#[error("Invalid email address: {0:?}")]
InvalidEmailAddress(String),

#[error("XML error at position {position}")]
#[error("XML error at position {position}: {error}")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasn't your PR wrt the FFI error reporting supposed to automatically print causes? Somehow manually chaining error descriptions like this seems a bit off, the anyhow::Error reporting-type with {:#} formatting should be taking care of this should it not? My guess is that the actual problem is that whoever reports/logs this doesn't report the causes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problem is, that's a thiserror error and thiserror does not do this: dtolnay/thiserror#98

@@ -12,7 +12,7 @@ pub async fn read_url(context: &Context, url: &str) -> Result<String, Error> {
match surf::get(url).recv_string().await {
Ok(res) => Ok(res),
Err(err) => {
info!(context, "Can\'t read URL {}", url);
info!(context, "Can\'t read URL {}: {}", url, err);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here in an ideal world, we wouldn't do any error logging and just report it up. On line 6 the cause should have a #[from] annotation so that you can just propagate using ? and be done. And someone much closer to the application should be doing the logging.

I think as a general rule "much closer to the application" for us means the FFI interface should be doing all the error logging. The rest of the deltachat core should be treated as a library and errors should be propagated out and not logged (bearing in mind there are always exceptions and practical obstacles. I'm well aware we are far away from being in that nice place)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problem is, this is during configure and many URLs are tried for autoconfig and if we do not find any, we just guess the config. So, if configuration fails, we don't know if the problem was that we could not read the autoconfig or that we could not reach the server. But we can return only one error. Of course we could add more info to this error (which is also shown to the user) but I don't really think that's worth it.

@Hocuri
Copy link
Collaborator Author

Hocuri commented Oct 10, 2020

Let's just merge it and upvote dtolnay/thiserror#98 and dtolnay/anyhow#111 so that maybe one day we can get closer to this ideal world but I currently have no idea how to realize @flub's ideas.

@Hocuri Hocuri merged commit bb50b9a into master Oct 10, 2020
@Hocuri Hocuri deleted the show-more-errors branch October 10, 2020 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants