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

Refactor error handling to use exceptions #1719

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Conversation

joerick
Copy link
Contributor

@joerick joerick commented Jan 6, 2024

cibuildwheel has up until now handled most errors by printing an error message to sys.stderr and calling sys.exit. Others were handled using Logger.error, depending on the context. We also had return codes, but these weren't explicitly defined anywhere.

This makes that convention more explicit and codified. Now to halt the program, the correct thing to do is to throw a cibuildwheel.errors.FatalError exception - that is caught in main() and printed before exiting. The existing behaviour was kept - if an error occurs within a build step (probably something to do with the build itself), the Logger.error() method is used. Outside of a build step (e.g. a misconfiguration), the behaviour is still to print 'cibuildwheel: '

I also took the opportunity to add a debugging option --debug-traceback (and CIBW_DEBUG_TRACEBACK), which you can enable to see a full traceback on errors.

(I've deactivated the flake8-errmsg lint rule, as it was throwing loads of errors and these error messages aren't generally seen in a traceback context)

cibuildwheel has up until now handled most errors by printing an error message to sys.stderr and calling sys.exit. Others were handled using Logger.error, depending on the context. We also had return codes, but these weren't explicitly defined anywhere.

This makes that convention more explicit and codified. Now to halt the program, the correct thing to do is to throw a cibuildwheel.errors.FatalError exception - that is caught in main() and printed before exiting. The existing behaviour was kept - if an error occurs within a build step (probably something to do with the build itself), the Logger.error() method is used. Outside of a build step (e.g. a misconfiguration), the behaviour is still to print 'cibuildwheel: <message>'

I also took the opportunity to add a debugging option `--debug-traceback` (and `CIBW_DEBUG_TRACEBACK`), which you can enable to see a full traceback on errors.

(I've deactivated the flake8-errmsg lint rule, as it was throwing loads of errors and these error messages aren't generally seen in a traceback context)
cibuildwheel/windows.py Outdated Show resolved Hide resolved
cibuildwheel/util.py Outdated Show resolved Hide resolved
cibuildwheel/options.py Outdated Show resolved Hide resolved
joerick and others added 2 commits January 19, 2024 17:30
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
cibuildwheel/linux.py Outdated Show resolved Hide resolved
cibuildwheel/errors.py Outdated Show resolved Hide resolved
@joerick
Copy link
Contributor Author

joerick commented Mar 2, 2024

A review here would be good too. It's not critical, maybe just a little code quality improvement. I'm not too attached to it though, we could drop the idea if the existing convention approach is preferred.

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

Successfully merging this pull request may close these issues.

None yet

3 participants