> On 21 Feb 2019, at 22:37, Esteban Maringolo <emaring...@gmail.com> wrote:
>
> Hi all, Sven, :-)
>
> I'm writing some client REST API code and need to handle errors in the
> call, and found that all Errors are direct descendants of the Error
> class, why aren't Zinc Errors descendants of a common ZnError class?
>
> Regards,
>
> Esteban A. Maringolo
I don't know, but note that the exceptions in Zinc-HTTP-Exceptions are not the
only ones used, there are also those in Resource-Meta and Character-Encoding,
and all system Networking errors (those are quite common, ConnectionTimedOut,
ConnectionClosed).
Zinc is certainly not 'closed' under its own exception set, it is too complex
for that.
I also typically allow code to throw exceptions freely, instead of trying to
handle them. I do try to make each exception as meaningful as possible (not
just self error: 'xyz'), but I tend to reuse existing exception classes in many
cases, if that makes sense.
And if you are a REST client, you also have to handle all HTTP exception
classes intelligently (you know, not found is not the same as unauthorised or
wrong request, often errors have a useful payload).
In my own REST client, I turn REST exceptions into something more meaningful,
and let the others bubble up. So, some high level code will basically do [ ]
on: Error do: [ ] but often with some logging.
This is not such an easy subject, but an interesting one.
HTH,
Sven
