gEDA-dev: [RFC] Blog: Error reporting & handling in libgeda

[Bernd Jendrissek]

On Nov 28, 2007 1:24 AM, Peter TB Brett <peter at peter-b.co.uk> wrote:
> 1. If possible, succeed.
>
> 2. If failure is inevitable, fail gracefully.
>
> 3. If normal operation may result in failure, use GError.
>
> 4. Assume that libgeda works.

In general I agree, but I wouldn't want the library to try TOO hard to
succeed.  It should never crash on any user input (defined as that
data which can be created with the interface - gschem and friends in
particular, but NOT vi foo.sch), but I think it's perfectly okay to
crash some interface contract violation.  I'd be hesitant to globally
replace g_assert with g_critical; that just seems like an invitation
to get silent file corruption.  Just how often do users *really* read
the log window?

> One example would be when an unknown object type is encountered; at the
> moment, libgeda often kills the program by calling g_assert_not_reached(),

That's a feature, not a bug!  I've been adding a new object type
OBJ_SLOT and the crash forced me to notice places where I should at
least think about what should happen.  If it had been just some
message in the log window, I would probably not have noticed.

Well YMMV I suppose, as I'm aware (only realized later) that
G_DEBUG=fatal_criticals would have given me the same visibility into
the problem with GDB.