Implement Error and DOMException. Add patterns for error handling.

[Herschel]

I've had this floating around on my hard drive for a bit -- there is room for improvement, feedback requested!

Addresses #28. Methods that throw an error were using an ad-hoc js! block to catch the error and transfer it back. However, this gets difficult when a method returns multiple error types. This PR adds macros to make error handling more consistent and easy.

• Implement Error and DOMException types.
• Implement a js_try! macro that works like js!, but also catches errors and convert them to a Result type.
  • This macro relies on TryFrom<Value> being implemented for both the value and error type.
  • Specifically for DOMException, these have the same type in JS, but different names. For the concrete exception types in Rust, FromReference and TryFrom is implemented to check that the name matches.
  • The implementation of js_try! isn't optimal, with lots of calls back and forth to JS. I expect this could be done much better, perhaps by adding serialization support for a Result type. I was more concerned with establishing the pattern of how the errors should be caught on the Rust side; the macro can be improved.
  • Unlike the js! macro, js_try! does a try_into internally.
• For calls that may return several different errors, an enum can be used, and the error_enum_boilerplate! macro is used to implement TryFrom<Value> for the enum.
  • This will try to convert the value to each variant in sequence.
  • My macro-fu is a little weak, so maybe the syntax for this macro should be different. Even better, I think this could be done as a custom derive if we're okay with that.
• As an example, the js_try! macro is used to return errors from these APIs:
  • Node::replace_child, Node::insert_before
  • WebSocket::new and WebSocket::close_with_status (thanks @Diggsey!)

Things left for a future PR:

• Backtraces (could be placed in the IError trait?).
• Using a crate such as failure.
  • It didn't seem like there was a consensus on this yet.
  • Use error-chain #21 specified that error-chain was too heavy, but failure might be more appropriate. It would allow us to upcast into a unifying Error type. Maybe it's more ergonomic for failing methods to return Result<_, failure::Error> instead of defining an enum-per-throwing-function. But I think it's nice to know explicitly what errors a function might throw.

[Diggsey]

This looks great!

A few comments:

• I wonder if js_try! should include the unwrap - given the way it is used, it's unlikely the caller will ever not want to unwrap the conversion, and if the macro performs it, then it can give nicer behaviour in case the unwrap fails.

• DOMExceptions should expose their type as an enum rather than a string.

• DOMExceptions should be constructible by type.

[koute]

So far this is looking really solid!

Thanks a lot!

[koute]

These two tests should be web_tests. (That is - they should be in a mod protected by #[cfg(all(test, feature = "web_test"))] so that the tests don't fail when they're being run under nodejs.)

[koute]

Very minor stylistic nitpick: use-ing these two would probably be nicer.

[koute]

Instead of stringify!($name) wouldn't it be better to print out self.name()? (That way errors upcast into a base type would still show the actual type.)

[koute]

Can't you just do let text = format!("{}", error); here? (:

[koute]

Since the comments I've made are pretty minor and this in general looks pretty solid (and I want to release a new stdweb with this soon) I'm going to merge it in for now. We can further tweak it as we go.

Thanks a lot @Herschel!