Skip to content

Need a way to subscribe to DriverWarning as events with a callback #2088

Open

Description

@vnktshr21

With warnings.warn, if users have to asynchronously process driver warnings, then they need to override the warnings.showwarning function with a custom handler which would process driver warnings differently. This implies a global override, more things for users to maintain and a possibility of not handling certain other warnings in the application correctly. Would be good to have a warning event mechanism built into driver session which the users can subscribe to, by passing a callback function. This event mechanism can co-exist with the current warnings.warn. This way, users can adopt whatever approach makes sense for the application.

ie:

  • if they want to raise exceptions for warnings, then they can simply do
    warnings.simplefilter("error", DriverWarning)
  • if they want to asynchronously handle warnings without stopping the execution flow, then they can do
    session.warning_event.subscribe(driverwarninghandler(DriverWarning)) and define
def driverwarninghandler(DriverWarning):
    <log to file, set a flag, push to a queue, raise few warnings and ignore others, etc>

Activity

  1. bkeryan commented on Mar 26, 2025

    @bkeryan
    Contributor

    It sounds like warnings.catch_warnings() may be thread-safe in future versions of Python:
    https://discuss.python.org/t/thread-safe-warning-filters/76074/10

  2. vnktshr21 commented on Mar 27, 2025

    @vnktshr21
    CollaboratorAuthor

    Along with thread-safe override option, it would help if warnings.showwarning could be overridden for a specific class of warning, even if its going to be a global override. That would work for the use case I've mentioned and would not need us to have an additional warning event mechanism in nimi-python. Could not find any issue/discussion already for this. Created a discussion topic.

  3. ni-jfitzger commented on May 28, 2025

    @ni-jfitzger
    Collaborator

    @vnktshr21 Is asynchronous handling actually useful?
    Do you know of specific warnings where it's okay to handle things that way?

    When I think of warnings, I think of things like the PLL coming unlocked and possibly invalidating data. That's not the sort of thing where I'd want to keep going.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions