hanji

Problem calls as soon as the view has rendered a rejected task: That makes the view the only thing standing between the error and the user. Whatever it renders is the entire report, and because the process exits immediately, the caller's own never runs either. A view whose does not take the second argument cannot surface the error. It returns its in-progress frame for , so a failed task prints something indistinguishable from one still running, and the error is discarded with nothing written anywhere. This is not hypothetical: 's migrate view had exactly that shape, so a failed migration reported and exited 1, with no message on stdout or stderr and no indication of what went wrong. Change now reports whether the view is able to receive the error, and prints it when the view is not. A view that does render the error suppresses the fallback, so there is no double report. The signal is the view's declared arity rather than a comparison of the rendered strings. Spinner views advance a frame between renders, so their and output differ by a character even when the error was ignored entirely — comparing strings reports success for exactly the views that need the fallback. Notes Views that already accept the error are unaffected. Success and pending paths are unchanged. passes (35 tests), identical to the unmodified baseline.