Eros：迄今为止最符合人体工程学且类型化能力最强的错误处理方案

Eros 是一个受 anyhow、terrors、error_set 和 thiserror 启发的 Rust 错误处理库，旨在为库和应用程序提供灵活的错误处理方式。

它遵循错误类型仅在调用者关心时才重要的理念，避免不必要的样板代码，支持无缝转换错误类型，并始终提供错误上下文。

通过示例代码展示了如何使用 Eros 实现无需样板代码的单个或多个错误类型处理、无缝转换错误类型以及为错误添加上下文等功能。

• Eros 理念

  • 错误类型仅在调用者关心时才重要，否则会阻碍易用性并产生不必要的干扰。
  • 处理单个或多个错误类型时无需样板代码，无需创建额外的错误枚举。
  • 用户应能够无缝地在完全类型化的错误之间转换。
  • 错误应始终提供导致错误的操作上下文。

• 无需样板代码

  • 示例代码展示了如何使用 eros::Result 和 eros::UnionResult 处理不同类型的错误，无需为每个错误类型创建单独的枚举。

• 无缝转换错误类型

  • 示例代码展示了如何使用 deflate 和 inflate 方法在不同类型化的错误之间进行转换。

• 错误具有上下文

  • 示例代码展示了如何使用 with_context 和 context 方法为错误添加上下文信息，以便更好地理解错误发生的原因和位置。

• 综合示例

  • 通过一个完整的示例，展示了如何结合使用 Eros 的各种功能，包括错误追踪、上下文添加、错误类型转换等，以实现更灵活和强大的错误处理机制。

use eros::{bail, Context, IntoDynTracedError, IntoUnionResult, TracedError};
use std::io::{Error, ErrorKind};

fn func1() -> eros::UnionResult<(), (TracedError<Error>, TracedError)> {
    let val = func2()
        .with_context(|| format!("This is some more context"))
        .union()?;
    let val = func3()
        .context(format!("This is some more context"))
        .union()?;
    Ok(val)
}

fn func2() -> eros::Result<()> {
    bail!("Something went wrong")
}

fn func3() -> eros::Result<()> {
    return Err(Error::new(ErrorKind::AddrInUse, "message here"))
        .traced_dyn()
        .context("This is some context");
}

fn main() {
    // Can add context to `ErrorUnion` when the `min_specialization` feature flag is enabled
    // let out = func1().context("Last bit of context").unwrap_err();
    let out = func1();
    println!("{out:#?}");
}

Something went wrong

Context:
        - This is some more context
        - Last bit of context

Backtrace:
   0:     0x5561eb054735 - std::backtrace_rs::backtrace::libunwind::trace::hc389a5f23f39a50d
                               at /rustc/8f08b3a32478b8d0507732800ecb548a76e0fd0c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:117:9
...
   4:     0x5561eb02e4e2 - eros::generic_error::TracedError<T>::new::h41e2123d6cf4fdd5
                               at /workspaces/eros/src/generic_error.rs:36:24
   5:     0x5561eafe8246 - x::func2::hc5bcba8eff1a9abd
                               at /workspaces/eros/tests/x.rs:17:5
   6:     0x5561eafe7f19 - x::func1::hc86226443a9fa2c0
                               at /workspaces/eros/tests/x.rs:7:15
   7:     0x5561eafe82dc - x::main::h6b82c0c63f51d406
                               at /workspaces/eros/tests/x.rs:28:15
   8:     0x5561eafea397 - x::main::{{closure}}::h9ec95e65e08ea0a5
                               at /workspaces/eros/tests/x.rs:27:10
...

仓库：https://github.com/mcmah309/eros

Reddit：https://www.reddit.com/r/rust/comments/1mw9jr1/introducing_eros_a_revolution_in_error_handling/

文章《kruci：一个终端用户界面库的复盘》

这篇文章是作者对自己开发的一个终端用户界面 （TUI） 库 kruci 的复盘。作者在开发一款名为 “kartoffels” 的游戏时，为了优化服务器端渲染的性能，尝试创建一个新的 UI 库来替代 Ratatui。他发现 Ratatui 在处理 Unicode 和布局时存在性能瓶颈，尤其是 diffing（差异计算）过程消耗了大量时间。于是，作者尝试通过构建一个基于 widget 树的 UI 库来避免重复绘制未改变的屏幕部分，并探索了如何处理事件、管理状态以及实现布局。尽管在布局方面取得了一些进展，但最终由于担心管理树结构和子树等的开销会超过避免 diffing 带来的收益，作者放弃了这个项目。他意识到，对于 “kartoffels” 游戏来说，Ratatui 已经足够好，而他应该将时间花在改进游戏本身上。

阅读：https://pwy.io/posts/kruci-post-mortem/

Reddit：https://www.reddit.com/r/rust/comments/1mw90g8/kruci_postmortem_of_a_ui_library/

Eanray：用 Rust 编写的简单光线追踪器

Eanray 是一个用 Rust 编写的简单光线追踪器，可将描述 3D 场景的 Lua 脚本转换为 PPM 格式的渲染图像。

它具备多种功能，如边界体积层次结构、多线程渲染、蒙特卡洛全局光照等，并支持多种几何体、材质、纹理映射和变换。用户可通过命令行传递 Lua 脚本路径来运行，未来计划增加更多特性。

• 项目简介：Eanray 是一个简单的光线追踪器，目前用 Rust 编写，可将描述 3D 场景的 Lua 脚本转换为 PPM 格式的渲染图像。
• 功能特性：目前的主要功能包括边界体积层次结构、多线程渲染（基于瓦片）、蒙特卡洛全局光照等，支持多种几何体（如二次曲面、盒子、常数介质、平面等）、材质（如电介质、漫反射、金属等）、纹理映射（如棋盘格、Perlin 噪声、图像等）以及变换（如平移、旋转）。
• 运行方式：目前只能接受 Lua 脚本作为场景描述，用户需通过命令行传递脚本路径来运行，输出 PPM 文件。
• 技术与资源：核心渲染器用 Rust 编写，用户需用 Lua 编写场景描述。参考了《Ray Tracing in One Weekend》系列书籍，使用了 Solar System Scope 的行星纹理。

仓库：https://github.com/melvic-ybanez/eanray

讨论：使用 Rust 进行游戏开发是一个巨大的幻想吗？

楼主在寻找合适的游戏引擎时，发现许多 Rust 游戏引擎存在维护状况不佳、功能受限等问题，感到困惑和沮丧。

帖子中列举了多个 Rust 游戏引擎及其存在的问题，如 bevy 的 ECS 设计和频繁变动、sdl2 等只是绑定而非完整引擎等。其他用户则从不同角度进行回复，有的解释了游戏引擎开发的复杂性，有的推荐使用 Godot 等成熟引擎结合 Rust，还有的讨论了 ECS 架构在 Rust 中的适用性等。

高赞回复：

这与其说是 Rust， 不如说是游戏引擎开发过程中投入的大量工作。像虚幻或 Unity 这样的“名牌”引擎，实际上耗费了数十万工时的开发时间。要求一个“生锈、维护良好、安全”的引擎，其实是一个很大的要求。如果你要求一个 Java 游戏引擎或 Python 游戏引擎，你也会有同样的疑虑。 作为一名游戏从业者，我的建议是：你应该试试 ECS。一旦你习惯了，它其实是一项很酷的技术。 至于引擎选择，我个人的流程图如下： 我想尝试一下这项技术，享受其中的乐趣 -> 继续使用 Bevy 或此处的其他选项 我只想制作一款游戏：2D -> Godot；3D -> Unreal

Reddit：https://www.reddit.com/r/rust/comments/1mw8k2g/is_game_development_in_rust_one_big_mirage/

--

From 日报小组 苦瓜小仔

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区