Zinc Error Hierarchy

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

El jue., 21 feb. 2019 a las 19:11, Sven Van Caekenberghe
(<[hidden email]>) escribió:
> > On 21 Feb 2019, at 22:37, Esteban Maringolo <[hidden email]> wrote:

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

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

I understand, and for the most part I have the same strategy.

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

I'm taking a similar approach, so I let code fail as early as possible
and let exceptions bubble up. So in this case I'm handling Exceptions
and also API errors and signalling them with a particular error class.
Although this API (CouchDB) doesn't have error codes or something
meaningful to use as a key to throw different exceptions.

> This is not such an easy subject, but an interesting one.

It certainly is.

Thank you.


Esteban A. Maringolo