Need Help

[Michael Stone]

On Tue, Mar 04, 2008 at 08:22:31PM -0500, Benjamin M. Schwartz wrote:
> Michael Stone wrote:
> | My central error-handling goal has been to compactly express my
> | assumptions in a form that will prevent them from being violated in
> | ignorance. Should I have different goals?
>
> 1. I find Rainbow very impressive, and I am sure you are well aware of the
> various arguments made regarding error handling.  

Thank you. While it's true that I'm aware of some arguments regarding error
handling, I'm always interested in improving. It seems like one of the
most regularly failed challenges in the craft of programming.

> In my view, restricting assertions to internal invariants provides an
> easy way of distinguishing problems in Rainbow from problems in
> Activities and other parts of the system.

True, but the convention that I have established of separating error
messages into contract-violations and 'everything else', recorded in
per-activity logs and in a daemon-wide log (/var/log/rainbow) would seem
to accomplish similar goals.

> 2. Among your goals, you might consider maximizing the ability of novice
> programmers to figure out what they've done wrong.  

It's not my primary goal, but I'll agree that it's worth considering.

> The wiki page on translation even goes so far as to
> recommend using gettext for error strings, so that users and
> administrators may debug the system without knowing English.

I'm still not convinced. Wouldn't we be better served by translating the
source code itself, or an overview of the source code like my 'Taste the
Rainbow' pages?

Consider: in my experience, debugging consists of searching the diff
between one's mental model and reality from which it follows that the
material which should be translated is the material which provides the
clearest, most accurate mental model of the problem.

Also consider: had there been an actual bug in Rainbow, which would have
been more useful to Waqas in diagnosing and fixing the problem:
translated error messages or better written or documented source code?

Put another way, doesn't this kind of error message uselessly duplicate
information that is best recorded in the failing assertion itself (and
in the name of the function containing it, in this case, 

  check_cwd(... [cwd=]/home/olpc/Activities/Qirat.activity)
      assert ck.negative(W_OK, 0)

?

> 3.  Did this assertion failure result in the termination of the Rainbow
> daemon?  

The present implementation calls clone() before executing any
activity-launching code. Termination of the child by failure to handle
the AssertionError is a design goal.

> Raising exceptions for input errors has the distinct
> advantage of allowing one to catch exceptions thrown further down the call
> stack, instead of exiting.  Note that when I say "specific exceptions", it
> would be perfectly reasonable to wrap up all errors due to permissions in
> a PermissionsException, etc.

First, what can I reasonably expect to accomplish by catching such an
exception? Second, given that the exception is being raised in a child
process that may have been compromised by malicious data, I'm not
terribly interested in informing the main daemon to the particulars of
the failure; the log file is quite sufficient for my purposes.

Michael