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.

Sign up for GitHub

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

Jump to bottom

Show more errors #1967

Merged
merged 2 commits into from
Oct 10, 2020
Merged

Show more errors #1967

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d6c15fa
Show more errors
Hocuri Oct 4, 2020
bee9d23
Show another error, just in case
Hocuri Oct 4, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/configure/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -574,14 +574,14 @@ 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

InvalidXml {
position: usize,
#[source]
error: quick_xml::Error,
},

#[error("Failed to get URL")]
#[error("Failed to get URL: {0}")]
ReadUrlError(#[from] self::read_url::Error),

#[error("Number of redirection is exceeded")]
Expand Down
2 changes: 1 addition & 1 deletion src/configure/read_url.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.


Err(Error::GetError(err))
}
Expand Down