On Donnerstag, 4. September 2008, Jiří Suchomel wrote:
Because of this:
// Most YCP developers never use the return value of UI::OpenDialog().
That is a fact, and it was meant as a statement of fact. But...
// Many of them probably don't even know that it has a return value.
...this is not due to a lack of documentation. To the contrary. It's always been there, and it's always been documented. http://forgeftp.novell.com///yast/doc/SL11.0/tdg/YCP_UI_OpenDialog_with_opti... http://forgeftp.novell.com///yast/doc/SL10.3/tdg/YUI_builtins_OpenDialog.htm... http://forgeftp.novell.com///yast/doc/SL10.2/tdg/YUI_builtins_OpenDialog.htm... http://forgeftp.novell.com///yast/doc/SL10.1/tdg/YUI_builtins_OpenDialog.htm... http://forgeftp.novell.com///yast/doc/SL10.0/tdg/YUI_builtins_OpenDialog.htm... (can't go further back there - we used to have a different server back then)
is relying on the fact that developers will check return value of UI::OpenDialog() even worse.
It's not relying on anything like that. But it's preventing the UI to continue
with invalid data.
From some problems you can recover; from some you cannot. In general, the UI
is _very_ forgiving when it comes to YCP UI code that does things wrong. Most
UI built-ins like UI::OpenDialog(), UI::ChangeWidget(), UI::QueryWidget()
complain in the logs when something is very wrong, but try to continue anyway
and assume (or return) some reasonable value.
But at some point you just can't go on regardless of application programmer
errors. And if UI::OpenDialog() failed (it catches exceptions thrown from
lower lib layers), there is no open dialog, so you cannot expect input from
that dialog.
In almost (?) all cases it's not UI::OpenDialog() that causes a program's
forceful termination but a UI::UserInput() that tries to work on the same
dialog that could not successfully be created. So it's actually not fatal to
do one thing wrong, but to try to continue without respect to any previous
errors.
I call that _very_ forgiving.
CU
--
Stefan Hundhammer