Looks good, however why not just call the enum: ´Error, instead of HandlerError` ?

I was looking for a name to differentiate this error (HandlerError) type from the ServiceError. Each error is thrown at a different app layer (presentation/delivery/UI and domain services). For me, the handler is what other web frameworks call "controller"·

If we remove the prefix, we should also remove the prefix from the ServiceError, should not we?

Other alternatives:

• WebError
• RequestError
• WebRequestError
• DeliveryError

In fact, maybe we should not use the suffix Error because the struct is inside the errors mod.

I think WebError is the best option I have now. If we have console commands, we could call them ConsoleError. I would like to use a name that quickly identifies the way the user is interacting with the application (delivery layer): console, WEB.

Usually, this type of error is thrown from handlers, that's why I call it HandlerError.

I like the name RequestError as it is the most explicit about what the error is about, (not the detail of the handler).

edit: Or even use errors::Request.

I like the name RequestError as it is the most explicit about what the error is about, (not the detail of the handler).

edit: Or even use errors::Request.

I've updated it. Now you can read:

• errors::Request::DescriptionIsNotValidUtf8
• errors::Request::TagsArrayIsNotValidJson
• ...

I came up with another alternative:

errors::BadRequest::DescriptionIsNotValidUtf8 (this implies two types of errors, not all of them are bad requests, the other type would be errors::RequestProcessing or errors::RequestHandling)