hoodiehq/hoodie.js — pull request #173 by gr2m (2013-11-24 17:04:43+00:00)
Title: frontend error handling

It's something that is on my mind for longer now. We do not have a proper, unified way to handle errors.

A good starting point could be [this discussion on StackOverflow](http://stackoverflow.com/questions/1382107/whats-a-good-way-to-extend-error-in-javascript).

I think throughout the code, the error properties differ. Sometimes it's `{ error: '...', reason: '...'}`, sometimes it's `{ name: '...', message: '...' }` and probably there are other variants.

I'd like to normalize it to `{ name: '...', message: '...' }`, as these are the standard properties of JavaScript's native `Error` Object.

And I'd like to ensure that plugin developers are doing the same. Maybe `hoodie.rejectWith` should always reject with an Error Object, that would make sense anyway, wouldn't it? Question is what the API should look like, so that `name` and `message` gets always set?

Maybe if only a string is passed

```js
message = 'nope, you stink!';
hoodie.rejectWith(message)
```

we reject simply with `new HoodieError({message: message})`.

If an object gets passed, we require a `message` property to be set, otherwise we throw a fatal error? So this

```js
message = 'nope, you stink!';
hoodie.rejectWith({ name: 'StinkyError', message: message, extraInfo: 'this and that'})
```

would reject with `new HoodieError(name, message, extraInfo)`. And the implimentation of `HoodieError` would look something like

```js
function HoodieError(properties) {
$.extend(this, properties);
if (! properties.message) throw 'FATAL: error.message has to be set.'
}
HoodieError.prototype = new Error();
HoodieError.prototype.constructor = HoodieError;
```

Any thoughts on it?