원클릭으로
error-handling
Error handling guidelines for NeMo-RL. Covers exception specificity, minimal try bodies, and else blocks.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Error handling guidelines for NeMo-RL. Covers exception specificity, minimal try bodies, and else blocks.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Configuration conventions for NeMo-RL. YAML is the single source of truth for defaults. Covers BaseModel/TypedDict usage, dataclass for internal classes, exemplar YAML updates, and forbidden default patterns.
Code style guidelines for NeMo-RL (Python and shell). Covers naming, indentation, comments, docstrings, reflection avoidance, and uv usage.
Interactive code review for NVIDIA-NeMo/RL pull requests. Checks out PR locally, reads existing comments, applies coding guidelines from skills, previews findings, and posts review comments. Also supports reviewing the current branch locally.
Build and dependency management for NeMo-RL. Covers Docker image building and running, uv usage, venv setup, and adding dependencies.
CI/CD reference for NeMo-RL. Covers GitHub Actions pipeline structure, CI triggering via /ok to test, and CI failure investigation.
Contribution conventions for NeMo-RL. Covers PR title format, commit sign-off, and CI triggering.
| name | error-handling |
| description | Error handling guidelines for NeMo-RL. Covers exception specificity, minimal try bodies, and else blocks. |
| when_to_use | Writing or reviewing exception handling; 'try-except', 'catch all exceptions', 'bare except', 'how to handle errors', during code review. |
When using try-except blocks, limit the except to the smallest set of errors possible.
Don't:
try:
open(path, "r").read()
except:
print("Failed to open file")
Do:
try:
open(path, "r").read()
except FileNotFoundError:
print("Failed to open file")
When adding a config option or branch, ask: what does the worst plausible misconfiguration do? If it silently
produces wrong results rather than an error, add a setup-time assert/raise so it fails loudly at startup
instead of corrupting a run.
Examples of silent-wrong worth guarding:
prev_logprobs while a loss flag zeroes it (advantage degrades to
garbage with no error).KeyError mid-run instead of a
setup-time check).Prefer failing at setup() time over a deep-in-the-loop crash; prefer a crash over silent garbage. If you
truly can't validate, surface a logged warning rather than nothing.