View Issue Details

IDProjectCategoryView StatusLast Update
0000456ascendpygtk guipublic2017-04-23 18:22
Reporterjohn 
Assigned Tojohn 
PrioritynormalSeverityminorReproducibilityhave not tried
Status confirmedResolutionreopened 
Product Version0.9.7 
Target Version1.0Fixed in Version0.9.8 
Summary0000456: METHOD error handling needs work
DescriptionWhen 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.
TagsNo tags attached.

Relationships

related to 0000488 resolvedjohn "FIX L, D, P[1..n].K, eps;" fails to throw error when "n" undefined 
related to 0000442 new Better exception handling into PyGTK GUI 

Activities

john

2010-12-29 22:47

administrator   ~0000663

possibly fixed in changeset 3120.

john

2011-01-10 23:30

administrator   ~0000666

need testing via [[ExtPy]] before we can count this one closed.

john

2011-02-25 13:25

administrator   ~0000679

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.

john

2017-04-23 18:22

administrator   ~0001018

Note: error_reporter_tree is improved and more robust now, but this basic issue (comment 679) is still going to be relevant.

Issue History

Date Modified Username Field Change
2010-04-15 11:58 john New Issue
2010-04-15 11:58 john Target Version => 1.0
2010-04-15 18:25 svn
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