error safety - Githubissues

dherman commented 6 years ago

We need to spell out our approach to error safety. This has come up in a few issues on the main repo:

nixpulvis commented 6 years ago

I think as a general rule of thumb, any possibility to "catch" JS exceptions and return Results should be used. This is in many ways one of the main promises of this library to me.

kjvalencik commented 6 years ago

I don't think the API should do a throw for expected failures. E.g., check and require should return Result instead of performing a JsError::throw.

It could follow the error_chain idiom and convert the errors to exceptions as part of the export macro.

pub fn check<U: Value>(&self) -> Result<'a, U> {
    U::downcast(self.value)
        .chain_err(|| ErrorKind::TypeError("type error".to_string()))
}

/* ... */

wrapped_method(call).map_err(|e| match e {
    e @ Error(ErrorKind::TypeError(_), _) => /* something like this? */
})

This may require modeling exceptions as panic to prevent mixing recoverable and unrecoverable result types.

neon-bindings / rfcs

error safety #11