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

Don't handle BaseException #3880

Open
ktbarrett opened this issue May 3, 2024 · 0 comments
Open

Don't handle BaseException #3880

ktbarrett opened this issue May 3, 2024 · 0 comments
Labels
category:codebase:scheduler relating to cocotb's coroutine scheduler, triggers, and coroutine objects type:feature new or enhanced functionality

Comments

@ktbarrett
Copy link
Member

There are several places in the cocotb codebase that handle BaseExceptions and do stuff to them/squash them ("manage" them). This is not ideal. Instead we should be catching only Exception and select BaseExceptions that are safe to catch, for example: AssertionError and pytest.Failed.

Places where this unsafe handling occurs:

except BaseException as e:

except BaseException as e:

except BaseException as e:

except BaseException as exc:

I suggest we move the pytest.Failed logic from cocotb.regression into cocotb._conf and setup a variable which will include all Exception types that should be caught in these circumstances.

managed_exceptions = (Exception, Failed, AssertionError, TestSuccess, SimFailure)

Closing #3787 and #3788 would help shrink that list and not create some potentially weird cyclic reference between cocotb._conf and cocotb.result.

@ktbarrett ktbarrett added type:feature new or enhanced functionality category:codebase:scheduler relating to cocotb's coroutine scheduler, triggers, and coroutine objects labels May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:codebase:scheduler relating to cocotb's coroutine scheduler, triggers, and coroutine objects type:feature new or enhanced functionality
Projects
None yet
Development

No branches or pull requests

1 participant