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