El jue., 21 feb. 2019 a las 19:11, Sven Van Caekenberghe (<[email protected]>) escribió: > > On 21 Feb 2019, at 22:37, Esteban Maringolo <[email protected]> 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
