This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Processor.process: catch exceptions by default, CLI: add --debug to let them explode #579
Labels
You can continue the conversation there. Go to discussion →
After today's tech call, the picture has become even larger. #576 offers a new alley for making implementors aware of these problems – by feeding PAGE validation failures (along with call stack context if necessary) into dedicated loggers. But most of these failures very likely would result in subsequent crashes of the follow-up processors anyway (because we cannot expect to make all of them robust against all sorts of input invalidities, even in the long term). Plus we already face the problem that processors can fail (due to exception or exit) on single pages (often only after computing a long series of pages correctly). This is not tolerable for a system aiming at productive use. So is option 2 above. Therefore, we already need a mechanism of catching a processor's exceptions and falling back to (say) the input page as output page. That very mechanism could then be used to let exceptions fall through when requested. This could be controlled on the command line with a new option (say
--debug
). The single place to handle this would beocrd.Processor.process
. (But for the page-wise fallback we would also need #322.) Processor implementors could then run (andmake test
) their code with--debug
and start catching the exceptions from the PAGE model themselves accordingly.Originally posted by @bertsky in #577 (comment)
The text was updated successfully, but these errors were encountered: