Skip to content

Replace unwrap() with proper error handling in capabilities.rs #17

@niklabh

Description

@niklabh

Description

oxide-browser/src/capabilities.rs contains approximately 77 uses of .unwrap(), mostly from:

  1. caller.data().memory.expect("memory not set") — panics if memory isn't initialized
  2. Mutex::lock().unwrap() — panics if a mutex is poisoned
  3. Various string/data conversions

While many of these are unlikely to fail in practice, panics in host functions crash the entire browser instead of gracefully reporting errors to the guest module. Replacing them with proper error handling would make the browser more robust.

Approach

  • For Mutex::lock().unwrap(): Consider using .lock().unwrap_or_else(|e| e.into_inner()) to recover from poisoned mutexes, or return a default/error value to the guest
  • For memory access: Return an error code (e.g., -1) to the guest when memory isn't available instead of panicking
  • For string conversions: Use unwrap_or_default() or return an error to the guest
  • Start with a subset — you don't have to fix all 77 in one PR!

Files involved

  • oxide-browser/src/capabilities.rs

Difficulty

Intermediate — good practice for Rust error handling patterns. Can be done incrementally (fix 5-10 unwraps per PR).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions