Skip to content

Project Sync transitioned to new success/error handling#98

Merged
febbraro merged 2 commits intodevelopfrom
feature/sync-error-handling
Oct 27, 2017
Merged

Project Sync transitioned to new success/error handling#98
febbraro merged 2 commits intodevelopfrom
feature/sync-error-handling

Conversation

@febbraro
Copy link
Member

This was the big daddy, but I think I got it. Required a lil bit of refactoring to make it all work.

@febbraro febbraro requested review from grayside and tekante October 26, 2017 18:08
Copy link
Contributor

@grayside grayside left a comment

Choose a reason for hiding this comment

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

Overall this looks good. It's the kind of PR that any holes will be missing from the diff. This also needs a user experience review for the messages in the context of any other command logging. On that basis, I think I'd like to take it out for a spin before finalizing an approval, unless you think we should get this in and be prepared for another follow-up for gaps and string adjustments.

}
} else {
cmd.out.Error.Fatal(err)
var workingDir, err = cmd.DeriveLocalSyncPath(cmd.Config, ctx.String("dir"))
Copy link
Contributor

Choose a reason for hiding this comment

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

Why does this work without the :=? When I've tried things like this before, I'd have err yelling at me.

Copy link
Member Author

Choose a reason for hiding this comment

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

:= is just a shorthand for not needing to var it. The var and = I believe is redefining it.

cmd.out.Error.Fatal(err)
var workingDir, err = cmd.DeriveLocalSyncPath(cmd.Config, ctx.String("dir"))
if err != nil {
return cmd.Error(err.Error(), "SYNC-PATH-ERROR", 12)
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, maybe we should define cmd.EXTERNAL_ERROR_CODE and so on for more clarity about the numbers? I realize that's outside immediate scope but reading this out of the context of the other PR this immediately jumps out at me as "why is this a number 12?"

Copy link
Member Author

Choose a reason for hiding this comment

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

I think some constants for standard error codes are probably a good idea. We can tackle that in another PR

@febbraro febbraro merged commit aca42a3 into develop Oct 27, 2017
@febbraro febbraro deleted the feature/sync-error-handling branch October 27, 2017 16:42
@grayside grayside added this to the v2.0 milestone Oct 30, 2017
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.

2 participants