-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Stone wrote: | On Tue, Mar 04, 2008 at 06:16:34PM -0500, Benjamin M. Schwartz wrote: |> According to my software engineering professors, a program should |> always handle any input data without an assertion failure. Assertions |> are for catching bugs in internal invariants. Therefore, any time an |> assertion failure is reached, it represents a bug. | | 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. 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. 2. Among your goals, you might consider maximizing the ability of novice programmers to figure out what they've done wrong. OLPC's goals include bringing in many developers who have no experience, so it is important the system be friendly to, say, Python programs written by people who don't know Python. 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. 3. Did this assertion failure result in the termination of the Rainbow daemon? It certainly seems like it could have, though your response suggests otherwise. Most programs simply exit after an assertion failure, because the failure indicates that the program's internal state is no longer sensible. 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. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzfXXUJT6e6HFtqQRAhSwAJ4lobW9HT6OWtonFQjQI93ppGlGwACfTgBv AaXnBTOaXz1QrfGlc80xupU= =YfUX -----END PGP SIGNATURE----- _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
