[yast-devel] libyui throwing exceptions

newer
[yast-devel] Unification of Fxx...

Martin Vidner

8 Jan 2008 8 Jan '08

11:21

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") -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Show replies by date

Stefan Hundhammer

8 Jan 8 Jan

12:08

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 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Stanislav Visnovsky

12:13

Dňa Tuesday 08 January 2008 13:08:42 Stefan Hundhammer ste napísal:

...

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.

Is this caught by /sbin/yast2 script and the proper popup for application crashing is shown? Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Stefan Hundhammer

12:17

On Tuesday 08 January 2008 13:13, Stanislav Visnovsky wrote:

...

Is this caught by /sbin/yast2 script and the proper popup for application crashing is shown?

It should AFAICS. CU -- Stefan Hundhammer 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

12:17

* Stefan Hundhammer [Jan 08. 2008 13:08]:

...

Any ideas how to handle this better?

In any case, a proper user information is obligatory. Crashing is not an option. Whats wrong with defining a return value (and actually checking it ;-)) for OpenDialog() (and similar functions currently raising exceptions) ? Can the control-center check exit codes and display a proper error message ? Klaus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Stefan Hundhammer

12:27

On Tuesday 08 January 2008 13:17, Klaus Kaempf wrote:

...

* Stefan Hundhammer [Jan 08. 2008 13:08]:

...
Any ideas how to handle this better?

In any case, a proper user information is obligatory. Crashing is not an option.

Well, it's no more crashing than the other way. Just read what I just wrote about that "No dialog existing" popup. The application is dead in either case.

...

Whats wrong with defining a return value (and actually checking it ;-)) for OpenDialog() (and similar functions currently raising exceptions) ?

Have you EVER seen any piece of code that actually checks the return values for any of those calls? Look through our code. There are no such checks. And even if there were, what would you expect to happen? Do you think it is realistic to add error handling code for UI syntax errors to all the places where it might happen? bool success = UI::OpenDialog(`VBox(`HBox(...), `HBox(...), ... ); if ( ! success ) { // We just messed up the dialog. Handle this self-made error. bool success = UI::OpenDialog(`Label("We just made a syntax error"), `PushButton("OK") ); if ( ! success ) { // Handle possible errors of the error handling code // Duh. Another OpenDialog() that might fail. // We just opened an endless recursion. } }

...

Can the control-center check exit codes and display a proper error message ?

Did you never see that "xmessage" window that no user likes (because it's always bad news)? CU -- Stefan Hundhammer 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

12:52

* Stefan Hundhammer [Jan 08. 2008 13:32]:

...

Well, it's no more crashing than the other way. Just read what I just wrote about that "No dialog existing" popup. The application is dead in either case.

Can we put a bit more information into the 'No dialog existing' popup ? Currently this message seems pretty useless to me.

...

...
Whats wrong with defining a return value (and actually checking it ;-)) for OpenDialog() (and similar functions currently raising exceptions) ?

Have you EVER seen any piece of code that actually checks the return values for any of those calls? Look through our code. There are no such checks.

Then we should change this.

...

And even if there were, what would you expect to happen?

Logging it and exiting with a proper, defined return code. To be picked up by the control center and reported in a user readable way.

...

Did you never see that "xmessage" window that no user likes (because it's always bad news)?

What's wrong with reporting bad news if there is no way around it ? Klaus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Stefan Hundhammer

13:01

On Tuesday 08 January 2008 13:52, Klaus Kaempf wrote:

...

* Stefan Hundhammer [Jan 08. 2008 13:32]:

...
Well, it's no more crashing than the other way. Just read what I just wrote about that "No dialog existing" popup. The application is dead in either case.

Can we put a bit more information into the 'No dialog existing' popup ?

Like what? Like the bizarre technical stuff the exceptions dump to the log file? What could a user do with this information? The message is "we messed up, and you poor user can't do anything about it". This is what all the methods we are employing are (more or less) already telling.

...

Currently this message seems pretty useless to me.

Of course it is. It's in the same league as "internal error".

...

...
Have you EVER seen any piece of code that actually checks the return values for any of those calls? Look through our code. There are no such checks.

Then we should change this.

...
And even if there were, what would you expect to happen?

Logging it and exiting with a proper, defined return code.

We are doing exactly this. Low-level, where it belongs, not scattered all over the place, thus introducing a gazillion lines of never-used error handling code that is full of bugs.

...

To be picked up by the control center and reported in a user readable way.

How can there be a user readable way for this? Do you expect the user to fix the YCP code? Did you read any of the exception messages? Did you find any that is not informative to a YCP application developer? (which is the target audience for this, not the end user)

...

...
Did you never see that "xmessage" window that no user likes (because it's always bad news)?

What's wrong with reporting bad news if there is no way around it ?

Where did I write that there is something wrong with it? CU -- Stefan Hundhammer 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf

13:14

* Stefan Hundhammer [Jan 08. 2008 14:01]:

...

On Tuesday 08 January 2008 13:52, Klaus Kaempf wrote:

...
Can we put a bit more information into the 'No dialog existing' popup ?

Like what? Like the bizarre technical stuff the exceptions dump to the log file?

I think we have sufficient of that ;-) How about "Ouch ! A YaST dialog was supposed to appear here but something went wrong. We're sorry for the inconvenience. Please ensure that your system is up-to-date. If this error persists, please report it on http://bugzilla.novell.com"

...

...
Logging it and exiting with a proper, defined return code.

We are doing exactly this. [...]

We have a list of properly defined exit codes from YaST to be used by scripts (yast command line interface) or control-center ? I didn't know that.

...

...
To be picked up by the control center and reported in a user readable way.

How can there be a user readable way for this?

See above. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

5959

Age (days ago)

5959

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Klaus Kaempf
Martin Vidner
Stanislav Visnovsky
Stefan Hundhammer