error-handler-advisor
改进 Rust 错误处理
Rust 开发人员经常为正确的错误处理模式而苦恼。此技能主动审查代码,并使用 Result 类型、带有 thiserror 的自定义错误类型以及正确的 ? 运算符错误传播来建议惯用的改进。
Descargar el ZIP de la skill
Subir en Claude
Ve a Configuración → Capacidades → Skills → Subir skill
Activa y empieza a usar
Pruébalo
Usando "error-handler-advisor". I wrote this function but I feel like the error handling could be better: ```rust fn get_user(id: &str) -> User { let user = db.find_user(id).unwrap(); user } ```
Resultado esperado:
This function will panic if the user is not found. Consider using Result to make errors recoverable:
```rust
fn get_user(id: &str) -> Result<User, DatabaseError> {
let user = db.find_user(id)?;
Ok(user)
}
```
The ? operator propagates the error to the caller, allowing them to decide how to handle it.
Usando "error-handler-advisor". How should I define errors for my library?
Resultado esperado:
For library code, use thiserror with specific error types:
```rust
use thiserror::Error;
#[derive(Error, Debug)]
pub enum MyLibError {
#[error("Invalid input: {0}")]
InvalidInput(String),
#[error(transparent)]
Io(#[from] std::io::Error),
}
```
This provides type-safe errors with automatic Display implementations and From trait implementations.
Auditoría de seguridad
SeguroStatic analyzer flagged 67 potential issues but ALL are false positives. The analyzer detected markdown syntax (backticks for inline code) as shell commands, error formatting strings as system reconnaissance, and YAML front matter as obfuscation. This is a legitimate Rust error handling documentation file with no executable code.
Problemas de riesgo alto (4)
Puntuación de calidad
Lo que puedes crear
Rust 新开发者学习
一个刚接触 Rust 的开发人员不确定如何正确处理错误。该技能解释了为什么 unwrap() 是危险的,并用具体示例演示了 ? 运算符。
库作者的代码审查
一个库维护者想确保他们的错误类型遵循最佳实践。该技能审查他们的 thiserror 定义并建议改进以获得更好的 ergonomics。
生产代码审计
一个准备部署的团队想要识别潜在的 panic 点。该技能扫描代码库中关键路径中的 unwrap() 和 expect() 并建议更安全的替代方案。
Prueba estos prompts
审查这个 Rust 函数并建议错误处理的改进。该函数使用了 unwrap(),我想让它更健壮。
帮助我为我的库设计自定义错误类型。我需要能够表示验证错误、IO 错误和数据库错误的错误类型。
为我的错误传播添加上下文。目前我的错误无法说明哪个操作失败了。
thiserror 和 anyhow 有什么区别?我的项目应该什么时候使用它们?
Mejores prácticas
- 对可失败的操作使用 Result 并使用 ? 运算符传播错误,而不是 unwrap()
- 为库选择 thiserror(特定的错误类型),为应用程序选择 anyhow(灵活的错误处理)
- 使用 .context() 或带有 #[error] 消息的 {0} 占位符为错误添加上下文以帮助调试
Evitar
- 在生产代码中使用 unwrap() 或 expect() - 这些会在错误时 panic
- 使用 String 或 &str 作为错误类型 - 失去类型安全和模式匹配
- 使用 let _ = operation() 忽略错误 - 至少应该记录错误
Preguntas frecuentes
什么时候应该使用 unwrap() 而不是 ?
thiserror 和 anyhow 有什么区别?
如何为错误添加上下文?
我的库应该返回 anyhow::Error 吗?
如何在错误类型之间转换?
Option 类型怎么办?
Detalles del desarrollador
Estructura de archivos
📄 SKILL.md