Skip to content
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

Core: Logging and Exceptional States #228

Open
M3ssman opened this issue Oct 7, 2022 · 1 comment
Open

Core: Logging and Exceptional States #228

M3ssman opened this issue Oct 7, 2022 · 1 comment
Assignees

Comments

@M3ssman
Copy link

M3ssman commented Oct 7, 2022

There's a need for detailed specifications regarding the handling of both Logging and Exception handling.

If OCR-D-Core modules shall be used as library for other client-applications - which I highly approve - the current zoo of logging is very heterogeneous and hard to configure at all (if not impossible). Further, the channels in/from diagnostic information streams is, according to current cli-specs, limited to STDERR . Recent logging may also be broadcasted to other listeners.

Second, invalid states within OCR-D components/classes/functions shall yield a domain specific OCRDException to

  • make clear from where exception rises (which is not trivial in client-apps including several libraries)
  • respect software development principles like hide internals and prevent tight coupling
@M3ssman
Copy link
Author

M3ssman commented Nov 9, 2022

How to balance between convenient short feedback when ocr-d used as framework and external usage as a library?
seems to be the main question.

Other topics:

  • How to remove (or at least decrease) settings using global state for logging - initLogging()
    Ease testing, prevent side-effects
  • What needs to be reported with which severity? - Review log level.

Recommendations and Proposals (Python)

  • Which log level makes sense in which context?
  • Rather use module-level logger.
    "A good convention to use when naming loggers is to use a module-level logger, in each module which uses logging, named as follows:
    logger = logging.getLogger(__name__)
    This means that logger names track the package/module hierarchy, and it’s intuitively obvious where events are logged just from the logger name."
    
  • when used as library, provide NullHandler which swallows by default all log records.
    "It is strongly recommended that you do not add any handlers other than NullHandler to your library’s loggers. This is because the configuration of handlers is the prerogative of the application developer who uses your library." 
    
    Examples:
    # python snippet
    initLoggin()
    logging.getLogger('ocrd').addHandler(logging.NullHandler())
    logging.getLogger('page-to-alto').addHandler(logging.NullHandler())
    
    # config ini excerpt - must add both logger and handler to overall loggers and handlers sections, too
    [logger_ocrd_processor]
    level=WARN
    handlers=nullHandler
    qualname=processor
    
    [handler_nullHandler]
    class=NullHandler
    args=()
    
    
  • Advanced logging Handlers like SMTP Mail Handler, HTTPHandler

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants