Error handling

This issue is to keep track of the discussion about to handle errors internally. Main discussions were had in a pull request here and here.

Currently the errors thrown store a status code internally so the ResponseWriter knows which status code to return in the case of an error. The advantage is that this allows for easily adding new errors in the future. The disadvantage is that this makes some of the classes less independent and mixes some reponsabilities. For example, this makes it more difficult to have CompositeAsyncHandler as a separate package. Not that this is necessary but it might be an indication that there is an issue with this.

[RubenVerborgh]

A factory is a definitely viable avenue indeed; it does feel a bit heavy to always have this injected (given how common errors are).

That would make me lean towards a more adapter-like solution, where (for instance) the back-end layer throws a simple “Not Found” / “Not Exists” error, which is a data object that is later translated into the right HTTP error. So basically, factory strategy, but the factory takes in data objects such that not all classes need this factory.

[joachimvh]

That would then have to be a dependency for most classes though.

The other option is going to non-Http errors as was already suggested before and have a handler somewhere at the end that converts them to status codes (probably called by the responseWriter). And if new errors are introduced they would require also making a new handler for them (which can be combined in a CompositeHandler as usual then).

Both of these do make #23 a bit harder to solve I think 😄