Error handling

[communitysolidserver]

Error handling

[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 :D

[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.

[RubenVerborgh]

We need to fix this. When reviewing #52, I see Http pop up everywhere because of this choice, and that feels very wrong, as this layer is HTTP-independent.

[rubensworks]

Maybe we want to make use of the factory pattern here, where we have an ErrorFactory that can be called to constructor errors of different types (that we define). During dependency injection, we could pass an HttpErrorFactory that would create HTTP-specific errors for our internal error types.

This would allows us to create other error factories later on, such as IpfsErrorfactory.

[RubenVerborgh]

We have nice HTML errors now; I think that's enough.