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

Handle different errors and provide nice error messages #162

Merged
merged 6 commits into from
Jul 30, 2019
Merged

Handle different errors and provide nice error messages #162

merged 6 commits into from
Jul 30, 2019

Conversation

dpordomingo
Copy link
Contributor

fix #160

current sourced could fail in different ways if ~/.sourced does not exist, also some errors are not nice from the user pov.

The commits in this PR fixes:

  • Make sure that ~/.sourced dir can be created when:
    • running init
    • running compose download
    • downloading 'docker-compose' script (when no installed 'docker-compose')
  • Return a proper error if the user tried to run web before init
  • Return a proper error if workdir.Active failed
  • Return a proper error if __active__ does not exist

@dpordomingo dpordomingo added the bug Something isn't working label Jul 24, 2019
@dpordomingo dpordomingo requested a review from a team July 24, 2019 13:55
@dpordomingo dpordomingo self-assigned this Jul 24, 2019
cmd/sourced/cmd/root.go Outdated Show resolved Hide resolved
cmd/sourced/cmd/root.go Show resolved Hide resolved
cmd/sourced/compose/compose.go Outdated Show resolved Hide resolved
@@ -88,6 +102,10 @@ Once source{d} is fully initialized, the UI will be available, by default at:

select {
case err := <-ch:
if shouldFailFast(err) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If removed, those errors will be wrapped by a new one, what's wrong in this case

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, you did this just to avoid wrapping, sorry. What I meant is that there's no need to fail fast here as it's already the last statement of the function.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah. it's a bit confusing

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll be happy if you propose a better name for this function that filters our errors

workdir.ErrMalformed
dir.ErrNotExist
dir.ErrNotDirectory

Considering it again, it might be better: isNamedError? wdyt @se7entyse7en?

The underlying problem, which is not trivial imo, is that compose.RunWithIO can fail in many ways, most of them unknown (or at least for me). And when running web command, we consider as "expected" all those unknown errors, and we just retry...
But when the error is "known" (from the list above), there is no sense to retry, and we can fail fast with a proper error message.

And I think that there is also another underlying problem: since we're bubbling errors in different places, without distinguishing them, then providing meaningful errors is a difficult task, and then we find these kinds of weird error messages from time to time.

Copy link
Contributor

Choose a reason for hiding this comment

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

you could eventually wrap also the first error an error occurred while waiting for the container to start or something along these lines.

Copy link
Contributor Author

@dpordomingo dpordomingo Jul 26, 2019

Choose a reason for hiding this comment

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

I think that refactors exceeds the goal of this PR.
But I pushed b5b2156 that might address your requirement about clarifying different errors that can be returned by openUI, and that will also avoid your initial —and legit— concern about

if failFast(err) {
  return err
} else {
  return error.Wrap(err)
}

Copy link
Contributor Author

@dpordomingo dpordomingo Jul 26, 2019

Choose a reason for hiding this comment

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

would that ☝️ be enough?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd prefer the refactor as it clearly separates the different types of errors, but it's not a big concern.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I understand your point, and I also think that this function might be too big and with different responsibilities inside, but I do really prefer to avoid refactors when hotfixing. Thanks for being nitpicking (because it helps a lot), and also for being flexible in this case 🙇‍♂️

cmd/sourced/dir/dir.go Outdated Show resolved Hide resolved
cmd/sourced/dir/dir.go Outdated Show resolved Hide resolved
@dpordomingo
Copy link
Contributor Author

you hide the reason for this error, right?

	if err := rootCmd.Run(os.Args); err != nil {
		log(err)
		os.Exit(1)
	}

how user will fix it?

@smacker nope. When command execution returns an error, it is printed automatically (I think that it's done by go-flags), so then we have:

  • Causing error,
  • Nice description with a high level error description.

e.g.

$ sourced status
/home/david/.sourced is not a valid config directory: it has no read-write access
Cannot perform this action, config directory is not valid

@dpordomingo
Copy link
Contributor Author

I think that all your suggestions were already addressed, so if you agree, this should be ready for the last review from @carlosms (who he is coming back "tomorrow" Monday)

case fmt.Sprintf("%T", err) == "*flags.Error":
// syntax error is already logged by go-cli
default:
printRed("Unexpected error")
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this redundant? I would not print anything in this case, it does not add anything useful for the user

$ sudo mkdir /tmp/aaa
$ HOME=/tmp/aaa sourced status
mkdir /tmp/aaa/.sourced: permission denied
Unexpected error

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was to provide homogeneous error messages, but I assume we can also remove it if it's unexpected;
Anyhow, that should not be "unexpected", will review what happened in that case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

78f80cd fixes that @carlosms

  • unknown errors will have no special message but the causing error itself,
  • fixed that example, that should be as it follows:
$ HOME=/root/User sourced status
/root/User/.sourced is not a valid config directory: mkdir /root/User/.sourced: permission denied
Cannot perform this action, config directory is not valid

@dpordomingo dpordomingo merged commit d9e2f32 into src-d:master Jul 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

source{d} CE v0.14.0-rc.1 doesn't seem to create ~/.sourced folder
4 participants