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

Replace using sys.exit with higher level error/logic handling, e.g. custom exception #4209

Open
3 of 4 tasks
beckermr opened this issue Mar 9, 2021 · 4 comments · May be fixed by #5255
Open
3 of 4 tasks

Replace using sys.exit with higher level error/logic handling, e.g. custom exception #4209

beckermr opened this issue Mar 9, 2021 · 4 comments · May be fixed by #5255
Assignees
Labels
duplicate::primary if an issue/PR has duplicates, this is the consolidated, primary issue/PR effort-high [deprecated] in-progress issue is actively being worked on source::community catch-all for issues filed by community members stale::recovered [bot] recovered after being marked as stale type::tech-debt identifies or resolves some technical debt

Comments

@beckermr
Copy link
Contributor

beckermr commented Mar 9, 2021

What is the idea?

We here at conda-forge use some of the conda build APIs for our work. The code has been getting an increasing number of sys.exit calls for errors, which are causing our jobs to die.

Instead, maybe the code should raise an error and then catch it at the highest level and call sys.exit? This preserves the internals for others while maintaining the same behavior.

Why is this needed?

sys.exit calls are harder to catch/debug when using conda_build as an API.

What should happen?

Review and ideally remove all sys.exit calls.

Additional Context

These sys.exit calls in conda-build are very painful for downstream users of the code base as a library (i.e., conda-forge). The reason is that in the python exception hierarchy has the SystemExit exception raised by sys.exit and the standard Exception at the same level (https://docs.python.org/3/library/exceptions.html#exception-hierarchy). This means when one calls sys.exit, the invoking code cannot catch that exception without resorting to explicitly catching SystemExit as opposed to a normal Exception. The slight change in exception handling API breaks (at least my) expectations as a user of the code and has created quite a few mystery code crashes in the bot over the years.

Can we use a standard exception here and then have the conda-build CLI code handle that exception and call sys.exit?

Originally posted by @beckermr in #5237 (comment)

Tasks

  1. cla-signed
    kenodegard
  2. cla-signed
    beeankha kenodegard
  3. cla-signed
    kenodegard
  4. cla-signed
@beckermr
Copy link
Contributor Author

beckermr commented Mar 9, 2021

cc @mingwandroid for viz

@jezdez
Copy link
Member

jezdez commented Jun 2, 2021

This was previously brought up in the community meeting and I just want to raise that this is a good idea and should instead be using a way that allows programmatic access to some of the internals. sys.exit is in my experience not a great way to handle runtime errors or even just code dead ends.

@jezdez jezdez added the effort-high [deprecated] label Jun 2, 2021
@jezdez jezdez changed the title don't use sys.exit Replace using sys.exit with higher level error/logic handling, e.g. custom exception Jun 2, 2021
@github-actions
Copy link

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

  1. Verify that you can still reproduce the issue at hand
  2. Comment that the issue is still reproducible and include:
    - What OS and version you reproduced the issue on
    - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!

@github-actions github-actions bot added the stale [bot] marked as stale due to inactivity label May 22, 2023
@beckermr
Copy link
Contributor Author

Not stale.

@github-actions github-actions bot added stale::recovered [bot] recovered after being marked as stale and removed stale [bot] marked as stale due to inactivity labels May 23, 2023
@kenodegard kenodegard added type::tech-debt identifies or resolves some technical debt source::community catch-all for issues filed by community members in-progress issue is actively being worked on duplicate::primary if an issue/PR has duplicates, this is the consolidated, primary issue/PR labels Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate::primary if an issue/PR has duplicates, this is the consolidated, primary issue/PR effort-high [deprecated] in-progress issue is actively being worked on source::community catch-all for issues filed by community members stale::recovered [bot] recovered after being marked as stale type::tech-debt identifies or resolves some technical debt
Projects
Status: 🏗️ In Progress
Development

Successfully merging a pull request may close this issue.

4 participants