Re: Unhandled exception?

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 27 May 2014 11:00:57 -0400
Phillip Susi <psusi ubuntu com> wrote:
> On 5/27/2014 6:04 AM, Chris Vine wrote:
> > Two subsidiary thoughts: as an alternative have you tried setting
> > the encoding to CP437? iconv() supports it on my system so glib
> > ought to also.
>
> Yes, calling set_encoding() fixed the exception, although iconv seems
> to be translating the 0xBD character incorrectly.
>
> That might work in this particular case if I know the input is CP-437,
> but how should this conversion exception be handled in general?  I
> tried catching and ignoring the exception, but read() leaves the bad
> characters in the stream, so trying again just keeps throwing the same
> exception.  How can you skip over the damn thing and move on?

If you want to treat input text as text, but don't know the encoding,
you are stuffed, so just catch the conversion exception and abort, or
try to deduce the codeset for yourself and abort when you fail.  If you
want to treat it as binary data, treat it as binary data and all will
be well.

> > Secondly, on the issue of exceptions, if you are reading the
> > IOChannel in a callback in the glib main loop I suspect glibmm is
> > swallowing the exception in order to protect the main loop,
> > although I haven't looked at glibmm's wrapper for executing
> > callbacks in the main loop for some time so I could be wrong.  It
> > is often better to swallow a throwing callback and print to
> > g_critical() than terminate the program, as you can use
> > g_log_set_always_fatal() to change the behaviour if you want.
> >
> > If I am right about glibmm protecting the main loop, I would be 
> > surprised if by swallowing the exception, glibmm caused gparted's
> > call stack to unwind.  You would expect that to do the opposite
> > (and exceptions can't propagate through glib's C layer to unwind
> > the stack anyway), albeit as you say probably rendering the program
> > useless.
>
> That is the bug I was referring to.  An unhandled exception is
> supposed to be a fatal error, resulting in abort().  By catching and
> ignoring the exception, glibmm is inviting all kinds of trouble.

I don't agree on that, as you know.  I prefer the programmer to be
given a choice (assuming that is what glibmm is doing here) according
to the appropriate log level fatality preference.  Call
g_log_set_always_fatal(G_LOG_LEVEL_CRITICAL) and your wish will be
glib's command.  But as I said above, you should really catch the
(fully documented) exceptions which might be thrown by
Glib::IOChannel::read() locally yourself and decide what to do about it.
Especially so in an asynchronous callback, where that is the only
opportunity you can ever have to deal with it.

Chris