View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000456||ascend||pygtk gui||public||2010-04-15 11:58||2017-04-23 18:22|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||1.0||Fixed in Version||0.9.8|
|Summary||0000456: METHOD error handling needs work|
|Description||When METHODS are run from the PyGTK GUI, the error_reporter_tree thing is used to determine if any errors were experienced, rather than the Proc_enum output of the Initialize function (ascend/compiler/initialize.c).|
The reasons for this had something to do with difficulty in communicating errors from various kinds of External Methods, I think such as [[ExtPy]]. This problem needs to be cleared up so that we can use our C-layer API more cleanly from the Python GUI.
|Tags||No tags attached.|
||possibly fixed in changeset 3120.|
||need testing via [[ExtPy]] before we can count this one closed.|
This bug is still a problem, and is not fixed. Currently the T.getSimulation(..) call causes problems because if an error is found in the 'on_load' method, an exception is raised, and the resulting simulation object is not returned.
A call that creates a new object should not raise an exception if it's possible that the returned object will still be needed for something.
Either getSimulation should not run a method automatically, or else failed methods should return their errors in another way.
Or, we need to fix the METHOD handling so that unimportant intermediate errors do not prevent successful overall completion.
||Note: error_reporter_tree is improved and more robust now, but this basic issue (comment 679) is still going to be relevant.|
|2010-04-15 11:58||john||New Issue|
|2010-04-15 11:58||john||Target Version||=> 1.0|
|2010-12-29 22:47||john||Note Added: 0000663|
|2011-01-09 19:09||john||Status||new => assigned|
|2011-01-09 19:09||john||Assigned To||=> john|
|2011-01-09 19:09||john||Status||assigned => resolved|
|2011-01-09 19:09||john||Fixed in Version||=> 0.9.8|
|2011-01-09 19:09||john||Resolution||open => fixed|
|2011-01-10 23:30||john||Note Added: 0000666|
|2011-01-10 23:30||john||Status||resolved => feedback|
|2011-01-10 23:30||john||Resolution||fixed => reopened|
|2011-02-25 13:25||john||Note Added: 0000679|
|2011-02-25 13:25||john||Status||feedback => assigned|
|2011-02-25 13:25||john||Status||assigned => confirmed|
|2011-02-28 15:43||john||Relationship added||related to 0000488|
|2011-02-28 15:44||john||Relationship added||related to 0000442|
|2017-04-23 18:22||john||Note Added: 0001018|