On Tue, Aug 5, 2008 at 2:00 PM, Peter TB Brett <[EMAIL PROTECTED]> wrote: > A few months back, I thought carefully about this and wrote a detailed blog > post about my conclusions. In particular, we assume that libgeda works -- > that is, libgeda functions always pass valid data to other libgeda > functions. We also try to avoid killing the application if we possibly can.
In general I agree with your thoughts on error handling here, but I'm a bit uneasy about the one-size-fits-all solution. There's a difference between "bad input, but could conceivably originate from user input / files" and "just totally insane" [*]. I realize it's a tradeoff between (noticing and finding bugs) and (limping along without crashing and losing the user's data) [parens for grouping]. As a programmer I'm much more comfortable with hard crashes in "insane" conditions instead of recovering, whilst as a user I obviously prefer the app not to dump core! It reminds me of those wretched messages from another OS that claim, "The application will now be shut down to prevent loss of data", but there's some truth in it: when you encounter "impossible" conditions, something's so deeply wrong (corrupted memory) that it really is safer to just abort right there and hope you had recently saved your work. I also like the documentation-by-code that assertions provide. They make a locally-visible promise about the state of variables. [*] Examples of what I consider "just totally insane" and abort()-worthy would be toplevel == NULL, or o_current->type != anything we know. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
