Need Help
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Tue Mar 4 20:22:31 EST 2008
-----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-----
More information about the Devel
mailing list