Files
werkrevisor/docs/prs/2026-10-12-PR#93-error-handling-question.md
claude-code 4b12300b47
werkator build succeeded after 00:10
werkator/werkrevisor-statistics build succeeded after 00:35
werkrevisor 0.37.0: the error handling category asks for lost or hidden failures (#93)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-12 14:39:51 +02:00

2.7 KiB

PR#93: The Error Handling Category Asks for Lost or Hidden Failures, Not for Changed Error Handling

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

Problem

The category error_handling of jvm-spring-backend asks whether a change alters error handling, retries, or what happens after a failed operation. That holds for almost every change of error handling, also a correct one. Jev rated the bounded retry of a commit status in werkator PR#155 at 0.98, so the PR became YELLOW; the Codex review rated it as not critical and found nothing.

Non-Goals

  • No change of the other categories.
  • A retry that is not safe to run twice stays with the category concurrency (PR#60).

Solution

  • The new question asks whether the change lets a failure go unnoticed: an exception caught and ignored or only logged at a low level, a failure reported as a success, an error result no longer checked, or a partial update no longer rolled back.
  • From 0.85 on, the category gives YELLOW; from 0.99 on, ORANGE, as before.
  • docs/werkrevisor.werkbaum: the measurement.
  • werkrevisor 0.37.0.

Measurement

On 2026-10-12 Jev (jev-latest) answered the old question and two new wordings for each main-code file of 30 merged werkator PRs (#125 to #154), of hs.hsadmin.ng #281 to #316, werkator PR#155 and seven constructed diffs. 27 of the 36 hs.hsadmin.ng PRs were merged; the other 9 were closed without a merge and are left out. 32 of the 57 merged PRs change main code; together they have 179 main-code files. The table shows the chosen wording.

case old question new question
defect: an exception around a save is caught and ignored 0.99 0.98
defect: a failed create answers 200 OK, logged at debug 0.98 0.95
defect: a failed credit after a debit is only logged, no rollback 0.97 0.87
defect: the result of publishing a final status is ignored 0.96 0.95
correct: a new exception handler answers 404 0.93 0.16
correct: a narrower exception type with a better message 0.97 0.38
correct: a changed log text 0.05 0.07
werkator PR#155: one retry of a commit status after an I/O error 0.98 0.23
57 merged PRs, highest value 0.95 0.69

From 0.85 on, the new question finds the four constructed defects and none of the merged PRs. The other wording, which asks for a failure hidden from the caller, the user or the operator, rated the missing rollback at 0.92 but the narrower exception type at 0.63. The defects are constructed and plain, so a real one may score lower.

Open Questions

None.