From a695aafafa953bcb65562bbb9f188cd458113890 Mon Sep 17 00:00:00 2001 From: Will Lachance Date: Tue, 17 Dec 2024 08:27:46 -0500 Subject: [PATCH 1/2] TRY300: Add some extra notes on not catching exceptions you didn't expect --- .../src/rules/tryceratops/rules/try_consider_else.rs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs b/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs index 65699ca6824911..59eb1902ced696 100644 --- a/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs +++ b/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs @@ -13,7 +13,9 @@ use crate::checkers::ast::Checker; /// ## Why is this bad? /// The `try`-`except` statement has an `else` clause for code that should /// run _only_ if no exceptions were raised. Using the `else` clause is more -/// explicit than using a `return` statement inside of a `try` block. +/// explicit than using a `return` statement inside of a `try` block. In general, +/// it is better to only have code which you expect could throw an exception inside +/// a `try` block to avoid accidentally catching something you didn't expect. /// /// ## Example /// ```python From 945079d6d0b6d5846676fc94385dff81c87c97f3 Mon Sep 17 00:00:00 2001 From: dylwil3 Date: Sat, 18 Jan 2025 10:14:59 -0600 Subject: [PATCH 2/2] tweak wording --- .../src/rules/tryceratops/rules/try_consider_else.rs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs b/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs index 59eb1902ced696..7b211b3f72b169 100644 --- a/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs +++ b/crates/ruff_linter/src/rules/tryceratops/rules/try_consider_else.rs @@ -12,10 +12,10 @@ use crate::checkers::ast::Checker; /// /// ## Why is this bad? /// The `try`-`except` statement has an `else` clause for code that should -/// run _only_ if no exceptions were raised. Using the `else` clause is more -/// explicit than using a `return` statement inside of a `try` block. In general, -/// it is better to only have code which you expect could throw an exception inside -/// a `try` block to avoid accidentally catching something you didn't expect. +/// run _only_ if no exceptions were raised. Returns in `try` blocks may +/// exhibit confusing or unwanted behavior, such as being overridden by +/// control flow in `except` and `finally` blocks, or unintentionally +/// suppressing an exception. /// /// ## Example /// ```python