ワンクリックで
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.