On Wednesday 06 August 2008 03:45:57 [EMAIL PROTECTED] wrote: > > Secondly, you're using g_assert() quite a lot. In particular, you > > assert > > that the object isn't NULL in o_shortest_distance(), but you then do > > exactly the same assertion in each of the type-specific functions! > > Yes. I like assertions. (Well, in C at least.) > > > 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. > > > > http://www.peter-b.co.uk/blog/2007/11/error-reporting-handling-in-libgeda > >.html > > I don't agree with the portion on assertions, but if it's the > philosophy of the project, I don't mind removing them. > > Asserts stop the program closest to the problem. Then, by looking at > the callstack (and possibly the stack frames), the developer can > isolate the problem quickly. If the program continues operation and > fails later, the developer has a more difficult time tracing down the > problem. The function may have already gone out of scope and it's > stack frame would not be available. The developer may not even know > all the preconditions and postconditions for all the functions that > executed, consuming more of the developer's time to analyze the code. > In this case, assertions not only document the pre/postconditions, but > also automate testing of the pre/postconditions during execution. > (Beats printf's by a mile.)
As I think I mentioned, the reason for doing it this way is *only* because
we're in library code -- I can't remember the full (very long) discussion I
had with Peter C, since it was a while ago -- but ideally, *library* code
should avoid killing the the application *if it can*, if possible letting the
application know something went wrong so it can kill itself. You see this
quite a lot in GTK+: it tries really hard not to crash, and appears to use
make extensive use of g_critical().
Note that if you really want assertion-like behaviour while developing, see
the documentation on environment variables which affect GLib:
G_DEBUG. If GLib has been configured with --enable-debug=yes, this variable
can be set to a list of debug options, which cause GLib to print out
different types of debugging information.
...
fatal_criticals
Causes GLib to abort the program at the first call to g_critical(). This
option is special in that it doesn't require GLib to be configured with
debugging support.
When I'm debugging libgeda (suppose I see criticals in the gschem log window)
I export that and run gschem in gdb.
By all means make heavy use of assertions to make sure *libgeda's* working
correctly -- I'm arguing against using them to second-guess the application.
I'm only saying that it's a bad thing to use them to sanity check input, if
you can get away with not doing so. In this case, you can -- return infinite
distance, as you are doing.
Finally, when I pointed at that blog when I wrote it, no-one had any major
objections, but I'd really like it if other devs weighed in. *poke*
Cheers,
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
