Exception type too broad in error handling
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- python
- Domain
- machine-learning
Research direction
No files or tests are identified in the issue. Search the Python codebase for bare except clauses and except Exception, inspect each handler's intended failure modes, and verify that handlers catch only exceptions they can handle without swallowing KeyboardInterrupt or SystemExit.
Written by the indexing model from the issue text.
Description
Bug Report
Description
Some except clauses catch overly broad exception types (e.g., bare except: or except Exception:), which can accidentally swallow important errors like KeyboardInterrupt or SystemExit.
Example
# Problematic:
try:
do_something()
except: # catches EVERYTHING including KeyboardInterrupt
pass
# Better:
try:
do_something()
except ValueError as e:
logger.warning(f"Value error: {e}")
Expected Behavior
Exception handlers should catch only the specific exceptions they know how to handle.
Impact
- Makes it impossible to interrupt the program with Ctrl+C in some cases
- Hides unexpected errors that should be investigated
- Makes debugging significantly harder
Suggested Fix
Replace broad except clauses with specific exception types wherever possible.
- Dominant language
- Python
- Stars
- 43.3k
- Forks
- 5.1k
- Avg merge
- 4d 20h
- Merged PRs (30d)
- 69
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from deepspeedai/DeepSpeed
-
[BUG] Universal checkpoint resume puts CPU `step` into fused/capturable optimizer statePossibly taken @ArjunPakhan claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
deepspeedai/DeepSpeed#8884 · 1 comment ·
Maintainers usually reply within 3 days
-
init_inference rejects dtype=torch.int8 on every acceleratorMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
deepspeedai/DeepSpeed#8577 ·
Maintainers usually reply within 3 days
-
[BUG] AutoTP checkpoint load raises AttributeError on a model containing nn.InstanceNorm1dPossibly taken @vineethsaivs claimed this 41 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
deepspeedai/DeepSpeed#8514 ·
Maintainers usually reply within 3 days
-
[BUG] Python checkpoint writers fail to reload full ZeRO-3 state with default torch.loadPossibly taken @ai-yang claimed this 42 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
deepspeedai/DeepSpeed#8500 ·
Maintainers usually reply within 3 days
-
[BUG] set_norm_for_param_grad_in_gpu's grad_accum fallback is dead in both accumulation modesPossibly taken @LOGO127 claimed this 51 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
deepspeedai/DeepSpeed#8371 ·
Maintainers usually reply within 3 days
All issues in deepspeedai/DeepSpeed
Similar issues
-
bug P2 rust
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
jscott3201/rusty-bacnet#2085 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
evarness-ai/iris-harness#401 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
sistemicorp/scripts#62 ·
-
area/mac help wanted needs-qa
Difficulty 1/5 Under an hour Newbie friendliness 76/100