- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
ID: ruby-best-practices/no-rescue-modifier
Language: Ruby
Severity: Notice
Category: Best Practices
This rule emphasizes the importance of not using ‘rescue’ as a modifier in your code. Using ‘rescue’ as a modifier can lead to confusion and potential bugs in the code. This is because it can catch exceptions you did not intend to catch and miss the ones you intended to catch. Hence, it’s considered a bad practice.
The importance of this rule lies in ensuring the clarity and correctness of your error handling code. When ‘rescue’ is used as a modifier, it can catch StandardError
and its subclasses by default. This can lead to unexpected behavior if you intended to catch a different exception.
Good coding practices to avoid this rule violation include explicitly stating the exception you are trying to catch, and using ‘rescue’ in a begin-end block instead of as a modifier. This makes your code easier to understand and less prone to bugs. For example, instead of writing foo = a[x] rescue nil
, write:
begin
foo = a[x]
rescue IndexError
foo = nil
end
This way, it’s clear that you are trying to rescue IndexError
, and not any other kind of error.
foo = a[x] rescue nil
something rescue handle_error
# This is a common mistake: it doesn't capture SomeException.
# It captures StandardError and names the variable `SomeException`.
anything rescue SomeException
try
foo = a[x]
rescue IndexError
foo = nil
end
try
something
rescue StandardError
handle_error
end
|
|
For more information, please read the Code Analysis documentation
Identify code vulnerabilities directly in yourVS Code editor
Identify code vulnerabilities directly inJetBrains products