Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Processor.process: catch exceptions by default, CLI: add --debug to let them explode #579

Closed
bertsky opened this issue Aug 27, 2020 · 0 comments
Assignees

Comments

@bertsky
Copy link
Collaborator

bertsky commented Aug 27, 2020

Thinking about this from the PAGE model is a different picture, though. Functions like add_TextRegion would have to throw some CoordsNotInParentException which needs to be handled differently in the caller/processor.

I think you might draw 2 different conclusions from that:

  1. Moving the check into the PAGE model implicitly is not worth it, because the processors still need to be updated (catching the exception), so one might as well keep it a separate function and opt-in (tolerating processors which don't use it and thus may produce inconsistent coords).
  2. Moving the check into the PAGE model implicitly allows us to enter a (non-production) phase where users will see exceptions as long as the respective processors have not been fixed.

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 be ocrd.Processor.process. (But for the page-wise fallback we would also need #322.) Processor implementors could then run (and make test) their code with --debug and start catching the exceptions from the PAGE model themselves accordingly.

Originally posted by @bertsky in #577 (comment)

@bertsky bertsky added discussion Diskussion/ Input aus der Gruppe erforderlich enhancement labels Aug 27, 2020
@OCR-D OCR-D locked and limited conversation to collaborators Dec 20, 2021
@lena-hinrichsen lena-hinrichsen converted this issue into discussion #774 Dec 20, 2021
@lena-hinrichsen lena-hinrichsen removed the discussion Diskussion/ Input aus der Gruppe erforderlich label Dec 21, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

3 participants