docs/design: Initial diagnostics design #108
Conversation
Reference: #24
bflad
added
documentation
There was a problem hiding this comment.
I like the proposal, I agree with the recommendation at the end, and I think you did a really great job with this document. Amazing work.
I think the part I'm not seeing explicitly called out here that we talked about informally is your idea of validation helpers like Not, and how the different approaches intersect with that kind of work.
I think as we make diagnostics more prevalent throughout the codebase and require provider devs to interface with them more often, we're going to run into more and more situations where we're going to want to discriminate between diagnostics using more than just their severity, that different types or kinds of diagnostics will merit different handling. And I think your proposal will do a good job of addressing that.
I left some comments asking for clarification on things, but I think the proposal is good, I'm mostly just asking so we can surface and record context.
| @@ -0,0 +1,293 @@ | |||
| # Diagnostics | |||
|
|
|||
| Early in the framework design, [errors were recommended over panics](./panic-error.md). This requires functions throughout the framework to appropriately handle error return values to ensure they are correctly returned back to Terraform for practitioner and developer feedback. Terraform CLI, however, allows two levels of contextualized feedback: warning and error diagnostics. Warnings generally signal an issue, but are not intended to prevent further execution, while errors generally will return early. This type of feedback is generally preferable over warning and error log entries, since Terraform itself is designed around human workflows and direct feedback, rather than a long running service or system. | |||
There was a problem hiding this comment.
This type of feedback is generally preferable over warning and error log entries, since Terraform itself is designed around human workflows and direct feedback, rather than a long running service or system.
This is a really good callout.
Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Reference: #24