error safety

[dherman]

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

• Not possible to recover from errors thrown by check neon#52
• model exceptions as panics neon#87
• exception (i.e., panic) safety neon#193

[nixpulvis]

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]

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.