unhandled exception / abort etc. ...

Michael Meeks michael.meeks at suse.com
Wed Feb 29 06:29:34 PST 2012

Hi there,

On Tue, 2012-02-21 at 16:55 +0100, Stephan Bergmann wrote:
> On 02/21/2012 04:07 PM, Michael Meeks wrote:
> >> In my experience, such exceptions typically indicate a programming error
> >> (either in actual program code, or in the way the bits of the program
> >> are combined into an installation set).  And for programmers, it is
> >> often more helpful to see the direct consequences of such error than
> >> some "helpful" mediation on LO's part (like the infamous "The user
> >> language cannot be determined" message, typically caused by some problem
> >> that has zero to do with any locale data, only leading devs to start
> >> searching in the wrong direction).
> >
> > 	Haha :-) indeed, however a pathalogical, silent abort, without even an
> > auto-save, or any message from the exception is rather unfortunate
> > too ;-)
> This should not be a "silent abort, without even an auto-save" 
> anyway---at least not in production builds where the sal signal handler 
> machinery should catch the abort.  (No idea what the current status is, 
> which configurations lead to which behaviour wrt. that signal handler.)

	So - it took me a while to get around to this, but luckily while I was


	I hit this. Interestingly on Linux we do get some (not particularly
helpful) console debug:

$ ./soffice /tmp/foo.odp 

terminate called after throwing an instance of

	And of course, no auto-save, no contents of the exception etc. etc. And
I imagine the same is true for all un-caught exceptions, including
(incidentally ::std::bad_alloc() ;-). I imagine that at the moment
actively discards document data left & right in the vast majority of
cases where it is not caught.

	So - again; what are the downsides of a pleasant wrapper around 'main'
that not only prints out the exception and contents on the console, but
triggers the save/crash handler nicely. Of course, we can disable that
for the 'interesting' cases on Linux where G_SLICE is set etc. so people
debugging will see something closer to the original throw in gdb.



michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot

More information about the LibreOffice mailing list