tohum - 项目快速启动工具
tohum 是一个强大的命令行工具(CLI),帮助开发者使用预定义的种子模板快速启动新项目,告别重复的项目配置工作。
主要特点
- 极速启动:基于 Rust 构建,可在数秒内完成新项目的创建,性能卓越
- 种子仓库(Silos):通过仓库系统组织项目模板,便于查找。支持使用官方仓库或为团队/组织创建自定义仓库
- 跨平台支持:可在 Linux、macOS 和 Windows 上无缝运行,支持通过 Cargo 安装或源码构建
快速开始
-
安装工具
cargo install tohum(需要 Rust 工具链)
-
查看可用模板
tohum silo list -
创建新项目
tohum plant @node/react-vite-ts my-awesome-app
可用模板示例
@go/cli- Go CLI 应用程序模板@node/cli-ts- 配置了 TypeScript 的 Node.js 项目@node/react-vite-ts- 使用 TypeScript 和 Vite 的 React 项目
项目采用 MIT 许可证开源。
为什么在Rust应用中使用结构化错误处理
主要观点
错误处理的心理负担
- Rust的错误处理机制迫使开发者朝正确方向前进(思考并单独处理每个错误)
- 尽管理性上认为这很有价值,但由于缺乏测试或倾向于忽略错误路径,样板代码常让人感觉不值得
- 相比其他语言中随意抛出字符串异常,Rust强制执行了应该做但经常被忽视的最佳实践
堆栈跟踪的价值讨论
- 使用结构化错误时,通过在不同上下文位置使用唯一的错误类型(如"哪个文件未找到"),错误本身就能指向唯一位置
- 可以通过搜索上下文信息直接定位问题,调用堆栈变得不那么重要
- 堆栈跟踪主要在调试意外panic时有用,因为panic没有手动附加的上下文
- 对于结构化错误,错误消息中的上下文通常足以调试
样板代码的优势
- 结构化错误可以替代手写的错误枚举文档
- 有类型检查器的帮助,避免文档快速过时
- 实际上样板代码就是枚举错误的过程
工具推荐
- Snafu库提供了anyhow/thiserror的最佳结合方式
- 提供了从字符串类型错误到具体错误类型的简便迁移路径
- 减少了为强类型错误添加上下文的样板代码
https://reddit.com/r/rust/comments/1kx0ak8/why_use_structured_errors_in_rust_applications/
Rust 错误源追踪示例
这是一个演示如何通过追踪错误源链来揭示隐藏在错误链中的宝贵诊断信息的 Rust 代码示例。
核心概念
什么是错误源(Error Sources)?
- 在 Rust 错误系统中,错误可以通过实现
Error::source()方法指向其底层原因,形成错误链 - 例如:网络错误 → IO错误 → 操作系统错误
- 默认情况下,rootcause 只显示顶层错误信息
- 启用源追踪后可遍历完整错误链,展示完整的诊断信息
主要功能
-
问题场景
- 许多错误类型(如
reqwest::Error)会包装底层原因,但只在顶层显示通用消息 - 这导致重要的诊断信息被隐藏
- 许多错误类型(如
-
解决方案
- 通过自定义
ContextFormatterHook启用源链追踪 - 设置
follow_source: true来追踪完整错误链 - 设置
follow_source_depth: None来追踪全部深度(无限制)
- 通过自定义
-
示例对比
- 不追踪源链:仅显示顶层通用错误消息
- 追踪源链:显示完整的错误链路,包括 DNS 解析错误等详细信息
实现要点
- 创建
ReqwestErrorFormatter结构体实现ContextFormatterHook - 通过
Hooks::new()安装错误格式化钩子 - 模拟 HTTP 请求失败场景(访问不存在的域名)
- 可为自定义错误类型实现类似功能
应用价值
显著提升错误诊断的清晰度和可调试性,帮助开发者快速定位问题根源。
https://github.com/rootcause-rs/rootcause/blob/main/examples/following_error_sources.rs
--
From 日报小组 Mike
社区学习交流平台订阅:
1
共 0 条评论, 1 页
评论区
写评论还没有评论