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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel