Opened 17 years ago

Closed 17 years ago

#1513 closed defect (fixed)

gdal.GetLastErrorMsg() function does not functioning

Reported by: dron Owned by: hobu
Priority: high Milestone: 1.4.2
Component: PythonBindings Version: 1.4.0
Severity: major Keywords:
Cc: warmerdam

Description (last modified by hobu)

How to reproduce:

>>> import gdal
>>> f = gdal.Open("/path/to/nothing")
ERROR 4: `/path/to/nothing' does not exist in the file system,
and is not recognised as a supported dataset name.

>>> gdal.GetLastErrorMsg()
''

Change History (6)

comment:1 by hobu, 17 years ago

Description: modified (diff)
Milestone: 1.5.0
Version: unspecified1.4.0

comment:2 by hobu, 17 years ago

hobu>	[17:06] FrankW: #1513 is related to this line http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/include/python/gdal_python.i#L91
	<gdaltrac>	[17:06] Ticket #1513: gdal.GetLastErrorMsg() function does not functioning, http://trac.osgeo.org/gdal/ticket/1513
	<hobu>	[17:06] but I'm not sure where to do the CPLErrorReset()
	<hobu>	[17:07] if we don't have UseExceptions() turned on (bUseExceptions), we silently fail with an error going to stderr like normal. At that time, we *reset the error* for lack of a better place to do it.
	<hobu>	[17:08] Any ideas? Things could get easily out of sync if you had to manually reset the error and check every return value (maybe that's what you're supposed and already doing anyway... I'm lazy though :)
	<hobu>	[17:13] szekerest: do you know if exceptions in swig are real classes with destructors and such? Maybe we could just do the error stack reset in the exceptions destructor if it has one
	<hobu>	[17:14] http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/include/cpl_exceptions.i#L58 exhibits the same problem, I think
	<szekerest>	[17:15] hobu: In C# the exception is a class but it is thrown right after the function returns to c#
	<hobu>	[17:19] do you think we should remove the CPLErrorReset() on Line 58 of cpl_exceptions.i and Line 91 of gdal_python.i (I think cpl_exceptions.i is derived from gdal_python.i, right?)
	<szekerest>	[17:25] hobu: I'm not sure we can safely remove that. Why do you think it's not necessary?
	<hobu>	[17:26] it blows away the exception stack so a later subsequent call can't do gdal.GetLastErrorMsg() and get anything back
	<szekerest>	[17:29] hobu: The various bindings should retrieve the error immediately after the function returns. So it's not necessary to retrieve it later.
	<hobu>	[17:30] maybe the pattern of retrieving the value later is a python-only thing then
	* hobu	[17:30] curses at our legacy :)
	<szekerest>	[17:34] hobu: the NG python should use this pattern. SWIG_exception retrieves the error message.
	<szekerest>	[17:35] IMO getting the error later makes it useless a bit.
	<hobu>	[17:37] in python, to maintain our backward compatibility, we'll need to do it though
	<hobu>	[17:38] I will only modify gdal_python.i to act this way. Hopefully FrankW will see this discussion and have an opinion

comment:3 by warmerdam, 17 years ago

Milestone: 1.5.01.4.2
Priority: highesthigh
Severity: blockermajor

If errors are not being turned into exceptions, then swig should *not* be clearing them.

I have reassessed this as a 1.4.2 issue.

comment:4 by warmerdam, 17 years ago

Cc: warmerdam added

comment:5 by hobu, 17 years ago

I have made a change in r11470 that I think fixes this issue. The autotest suite seems to run without trouble.

comment:6 by hobu, 17 years ago

Resolution: fixed
Status: newclosed

Seems to be working now. r11533

Note: See TracTickets for help on using tickets.