This repository has been archived by the owner on Sep 14, 2020. It is now read-only.
Log the framework-provided exceptions with no stacktraces #159
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Do not print stacktraces of internal temporary/permanent errors, just log the message.
Description
Shorter logging
The internal temporary and permanent errors are special exceptions to control the framework's flow of handler execution: either to retry it, or to stop trying — regardless of the global mode on arbitrary error handling (in the assumption that
retry_on_error
will be exposed to the users some day).They are supposed to already contain the information needed to identify the cause of the problem. Stacktraces are not needed (they are needed only for the unexpected errors with unclear origin).
Instead, stacktraces of these special errors make it difficult to identify when an actual unexpected errors happens (by visually or automatically looking for stacktraces in the logs).
Therefore, the stacktraces are removed for these special error — and only for them. All unexpected arbitrary exceptions still have stacktraces as before.
Exceptions renamed
As a little refactoring, the exception classes are renamed for clarify, and to remove the mentions of "handler" from their names:
kopf.HandlerRetryError
-->kopf.TemporaryError
kopf.HandlerFatalError
-->kopf.PermanentError
The old names are kept as the aliases (so they still can be used as
kopf.HandlerRetryError/kopf.HandlerFatalError
in try-except clauses or any other places).Types of Changes
Review