-
Couldn't load subscription status.
- Fork 881
Make errors structured #1937
Make errors structured #1937
Conversation
rkt/rkt.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
common.NewErrorSanitizer is only called in the rkt binary but not in stage1's binaries (init or gc). How does it print the errors when the errors are not generated from the rkt binary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right. We need to separate the idea of making the errors structured and outputting the errors. For stage1 binaries, the errors have now been structured but I haven't dealt with output part yet. A large majority, if not all, of the output for stage1 goes to log.
Currently the wrapped errors will only show the outer most message. Will probable need to change that.
common/errors.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
designed to handle ...
c2b21e7 to
4c7935e
Compare
|
This is close to the final PR. Need to fix the tests now. |
|
Please review. I'm currently working on getting the tests to past but the main code is pretty much where I want it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch!
rkt/config/config_test.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if there is a point in using errwrap in unit tests.
store/store.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd remove that populateSize(): prefix.
|
About |
|
There're some |
|
Missing wrapping: https://github.com/coreos/rkt/blob/dc837ae7fe6f36552cf3bcde7b938f307361c7d2/stage1/common/run.go We should document this new way of handling errors (for example, in hacking.md) so developers use it. |
|
Otherwise, LGTM. I'm sure we're missing some things but we'll fix them eventually. |
9d25ed6 to
f028b20
Compare
errwrap provides a means of structuring error messages.
Up to now errors in rkt have been a concatenated string. This often ended with the user being presented with a very long, hard to decipher error message. Furthermore, sometimes the message was prefixed with the name of the command, sometimes not. In essencce, errors messages were inconsistent and confusing. This patch introduces structured error messages using the errwrap package. The goal is to have errors be useful & consistant, and have a single location (common/errors.go) where we can modify the error output. Errors are stored as an inner and outer errors. We do this by nesting errors using errwrap.Wrap. With this structure we have much more control over how we can display errors.
This change creates a new type, Logger, that wraps go's own Logger type
to provide consistent output across go commands. Along with the methods
from go's log package, there are also methods that accept our structured
error type introduced in the previous commit. These commands append an
'E' to the end of the familiar methods. For example, we now have
'PrintE', 'PanicE', & 'FatalE'.
With this, we have one, central location to modify the way output is displayed in
rkt.
The output generated when printing errors is:
```
cat-manifest: problem retrieving pod: no matches found for "asf"
```
or when using the `--debug` flag we'll get the entire error stack.
```
cat-manifest: problem retrieving pod
└─unable to resolve UUID
└─no matches found for "asf"
```
From this example we can see that when no `--debug` flag is used, you
get the innermost error as the last output on the line. All other errors
are hidden. This text between the 'command name' is the programmer
defined message that accompanies the errors sent to output. This can be
left empty.
When using the `--debug` flag we only get the 'command name' and
accompanying message on the first line. Under that we get the unwound
error messages, with the innermost one at the bottom.
Furthermore, all output to stderr has a prefix that is either
programatically set using the command or subsommand name, or one set in
the package.
refs: rkt#1550
fixes: rkt#1754
This makes casing for diagnostic and error messages consistent across rkt.
With the changes in error and diagnostic tests, some strings needed to be updated.
f028b20 to
23b4412
Compare
This PR is intended to get feedback on the general approach.
Up to now errors in rkt have been a concatenated string. This often
ended with the user being presented with a very long, hard to decipher
error message. Furthermore, sometimes the message was prefixed with the
name of the command, sometimes not. In essencce, errors messages were
inconsistent and confusing.
This patch introduces structured error messages using the errwrap
package. The goal is to have errors be useful & consistant, and have a
single location (common/errors.go) where we can modify the error output.
The common/errors.go provides a type called ErrorSanitizer that manages
error output. It is set up in the cobra.Command's PresisentPreRun func
so that each subcommand is able to initialize
errOutwith theevaluated --debug flag. This also allows each subcommand to set the
prefix appropriately. It uses the --debug flag to decide whether to show
just the inner-most error or all errors. The format of the error with
--debug=false is...
With --debug=true the output show all the errors.
In this case only one more but some errors are 5 or more deep. See
#1550 for an example.
This change does not change messages that are simply printing
a message to stderr. These still use the stderr function.
This change only handles errors but it may be useful to make
ErrorSanitizer a more general "output" type that handles all output to
console in a central place.
I think the ErrorSanitizer methods
PrintandErrorcould be better named. Also I'm thinking it may be better to have the error message only be on one line when--debugis false. For example, the one line output could be...and the
--debug=trueoutput could be...This PR will intend to fix #1550 and #1754.
Note: This will not pass the tests because the tests parse error output and I've not yet updated those.