Daniel Rall wrote:
> I expect errors to be caught and turned into something meaningful as
> close to where they're generated as possible (e.g. FS errors which
> need sensitive info stripped out), not way out at the client layer --
> outside the client library -- where there are a large number of
> possible error codes to handle.
Your expectations are, I think, the same as mine in terms of intent. But
they differ drastically from reality. And I think they differ in execution,
too.
A policy of transforming errors into meaningful ones "as close to where they
are generated as possible" is, as stated, a bit naive. See, "meaningful" is
a property assigned by a consumer, not a producer. No piece of code that
calls an API can know that that API has returned a specific-enough error
code unless that API promises to return specific codes for specific
problems. Outside of such promises, all code must assume that errors
returned from called functions aren't specific or meaningful enough, so all
code finds itself wrapping error messages, and collapsing hosts of error
codes into a smaller, more focused set of codes. This process of
summarizing many different error codes into a smaller, more focused set of
codes -- while preserving all the while the original code -- is how good
error reporting is done.
When the command-line client tries to call the public API svn_client_cat(),
it should be able to trust the promise that svn_client_cat() will only
return, say, 10 or so different, explicitly listed error codes. And
svn_client_cat() should ensure that it only ever returns error codes from
within that group of 10 or so codes it promises to return. And yes, that
might mean that it does error combination -- that 5 or 6 different codes all
related to trying to read the .svn/entries file get collapsed into a single
SVN_ERR_CANT_READ_ENTRIES_FILE or something, or that the nineteen things
that can go wrong while grabbing those file contents across the wire get
collapsed into SVN_ERR_CLIENT_CANT_FETCH_CONTENTS, but:
* no information is lost here due to our nested error codes, and
* a smaller set of explicitly listed return code possibilities empowers
callers to test for and automatically react to error conditions, if
only to use that information in categorizing and re-raising the error
to *their* callers in a predictable fashion.
> Error messages which we control that have descriptions which mention
> MKCOL or MKACTIVITY or whatever can likely be improved directly.
We have the power to control *all* error messages provided to our users. We
just tend to relinquish that power because it makes things simpler to code.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Aug 7 16:50:11 2006