Mailinglist Archive: yast-devel (101 mails)

< Previous Next >
Re: [yast-devel] libyui throwing exceptions
  • From: Stefan Hundhammer <sh@xxxxxxx>
  • Date: Tue, 8 Jan 2008 13:08:42 +0100
  • Message-id: <200801081308.42861.sh@xxxxxxx>
On Tuesday 08 January 2008 12:21, Martin Vidner wrote:
URL: http://svn.opensuse.org/viewcvs/yast?rev=43316&view=rev
Log:
- Fixed crash when running text-mode menu as
non-root user (new libyui throws an exception
if SelectionBox entry is nil)

Hi,

so I learn that the new libyui throws exceptions in certain cases
and some of them are not caught, causing yast to abort.

I understand that such cases are errors in libyui usage and fixing
the individual cases like this one is fine. Still, YaST should not
crash.

Shouldn't we revert to the old behavior of graceful degradation
where the YCP code gets nil and manages to recover? I suppose that
it can be done by one catch somewhere in the UI bindings.
(The log should say "libyui usage error, please report in bugzilla,
search for 'WidgetItemIsNilException' first")

In cases where it makes sense to continue, those exceptions are caught, and an
error value (typically nil) is returned to the YCP application. For example,
UI::ChangeWidget() and UI::QueryWidget() should always catch exceptions.

But what should UI::OpenDialog() do? The application excepts that new dialog
on the screen. It wants to access the newly created widgets. It expects
events (UserInput()) from those new widgets, not from whatever dialog happens
to be on the screen behind that dialog that could not be created.

The old UI had posted that well-known "No dialog existing during UserInput()"
error popup (at least the Qt version). But the effect is just the same as a
plain abort() due to an unhandled exception: The application is dead. Game
over. A user can't continue from there. All data he might have entered are
gone.

Just to clarify: This kind of situation is most always a programming error
somewhere in the application (syntax error when creating the dialog). It
needs to be fixed in the application. There is typically nothing a user can
do about it.

Any ideas how to handle this better?


CU
--
Stefan Hundhammer <sh@xxxxxxx> Penguin by conviction.
YaST2 Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Nürnberg, Germany
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
References