ElyOffice/tasks/reviews/C01.2c-r1.md

FAIL

Ran: cargo test -p ely-platform (all pass, including tests/startup.rs), cargo clippy -p ely-platform -p ely-ui --all-targets (clean), ELY_NO_DIALOG=1 tests/scripts/apps-start.sh (8 of 8). Also built a scratch probe against the pinned gpui 1a28cff with runtime_shaders, the same features the apps use: catch_unwind(|| gpui_platform::application().run(|_| panic!(..))).

1. crates/ely-ui/src/run.rs:22-35 — on macOS the catch_unwind never catches a startup panic. gpui runs the run callback from did_finish_launching, an extern "C" fn (gpui_macos/src/platform.rs:1317). A panic there cannot unwind, so the process aborts. Scenario: the probe printed panic in a function that cannot unwind … thread caused non-unwinding panic. aborting. and exited 134, without printing caught. So open, ely_gpui_component::init, Theme::set_mode_now, Shell::new and Metal renderer creation (expect("error building metal library"), gpui_apple/src/metal_renderer.rs:219-224) all end in an abort with no dialog and no "could not start" text. Windows behaves the same way inside extern "system" window_procedure. Fix direction: install the failure path in a panic hook (logging::init_in already sets one) so it runs before the abort, or have it call startup::fail from the hook during startup. Do not rely on unwinding out of run.

2. crates/ely-ui/src/run.rs:57-68 — the "window did not open" branch cannot catch the case §4.1 is about on macOS. MacPlatform::open_window returns Err only for AnchoredPopup (gpui_macos/src/platform.rs:693). The renderer is built without returning a Result (gpui_macos/src/window.rs:1101). When no Metal device is found, gpui logs and calls std::process::exit(1) (gpui_apple/src/metal_renderer.rs:205-208). Scenario: on a Mac or VM without a usable Metal device, ElyDoc exits 1 with only gpui's log line. No dialog appears and startup::fail never runs, which breaks "无法初始化图形后端时显示原因". Fix direction: check for a Metal device yourself before run (macOS), or do the equivalent wgpu adapter probe (Linux/Windows), and call startup::fail with the reason. Alternatively, patch gpui so renderer creation returns Err through open_window, and record it in patches/.

3. crates/ely-ui/src/run.rs:22-35 — on Linux, where the event loop is Rust and panics do unwind, catch_unwind covers the app's whole lifetime, not just startup. Scenario: a panic an hour into editing unwinds out of run, and the user sees "ElyDoc could not start … the graphics backend did not start: ". That is a false reason in the log and the dialog (rule 2: no masking or mislabeling). Fix direction: limit this path to startup. For example, set a "started" flag after the first window opens and stop treating later panics as startup failures. The real panic text should go through the normal panic path.

4. tasks/TASKS.md:21 — "本机验证：…窗口打不开与启动期 panic 都走这条路" has no evidence. No test or script makes a window fail or makes a startup panic go through run. tests/startup.rs calls startup::fail directly, and apps-start.sh covers only the success path. Findings 1 and 2 show the claim is false on macOS, the only machine it was "verified" on. Fix direction: add a test or smoke hook that triggers a startup panic and a window-open failure through ely_ui::run (for example an env-gated fault in a test binary) and asserts exit 1, the stderr text and the log line. Until that passes, move these two paths under 未验证.