[Fdo-trac] [fdo-trac] #1001: Where possible, the GDAL provider should try to include the result of CPLGetLastErrorMsg() in its exception message before throwing

[FDO]

#1001: Where possible, the GDAL provider should try to include the result of
CPLGetLastErrorMsg() in its exception message before throwing
---------------------------+----------------------
 Reporter:  jng            |        Owner:  jng
     Type:  defect         |       Status:  closed
 Priority:  major          |    Milestone:  4.2.0
Component:  GDAL Provider  |      Version:  4.1.0
 Severity:  3              |   Resolution:  fixed
 Keywords:                 |  External ID:
---------------------------+----------------------
Changes (by jng):

 * resolution:   => fixed
 * status:  assigned => closed

Comment:

 In [changeset:"8385" 8385]:
 {{{#!CommitTicketReference repository="" revision="8385"
 Include the underlying GDAL error in GDAL provider exceptions

 The GDAL provider reported failures such as "Fail to get image
 information."
 (GRFP_95) without the reason GDAL had already recorded via
 CPLGetLastErrorMsg(),
 so an unreadable or unsupported raster produced an undiagnosable error.
 The OGR
 provider has surfaced CPL errors through its CHECK_CPL_ERROR macro since
 r8060;
 the GDAL provider did so only in the tile read/resample paths, and the
 GDALOpen
 in FdoRfpDatasetCache::LockDataset discarded the error outright.

 The detail is now carried by the message catalogue rather than
 concatenated in
 code, so each symbolic id declares for itself whether it is parameterized:
 the
 affected messages take a %1$ls, which is the GDAL/OGR error text.

 Changes:
 - Providers/GDAL/Src/Message/GRFPMessage.mc:
   - GRFP_95_CANNOT_GET_IMAGE_INFO is now parameterized:
     "Fail to get image information. %1$ls".
   - Added four parameterized messages for the raster read failures that
     previously threw the raw CPL text with no symbolic id:
       GRFP_111_CANNOT_READ_RASTER_TILE          (GDALDatasetRasterIO
 failure)
       GRFP_112_CANNOT_OPEN_RESAMPLED_DATASET
       GRFP_113_CANNOT_OPEN_TILE_DATASET
       GRFP_114_CANNOT_CREATE_WARP_OPERATION
 - Added FdoRfpRasterUtil::GetLastGdalErrorMessage(), which reads
   CPLGetLastErrorMsg(), converts it to a wide string and calls
   CPLErrorReset() so that a stale error cannot be attributed to a later,
   unrelated failure on the same thread - the defect the OGR provider fixed
   in r8351.
 - FdoRfpGeoBandRasterImp, FdoRfpStreamReaderByTile and
   FdoRfpStreamReaderByTileResample now throw the messages above with the
 GDAL
   error as %1$ls, replacing the duplicated
   multibyte_to_wide(CPLGetLastErrorMsg()) blocks.
 - Declared the .mc as a dependency of every generated message header and
   catalogue (FDO core, SchemaMgr, and the GDAL/SDF/SHP/WFS/WMS/KingOracle/
   GenericRdbms providers). Without it, an incremental build kept the
 previous
   catalogue text and silently dropped the %1$ls argument.
 - Added RfpNoConfigTest2::testUnreadableRasterReportsGdalError and the
   synthesized fixture TestData/VRT/ticket1001_unreadable.vrt: a lazy VRT
 whose
   source file is deliberately absent, so GDALOpen succeeds and the first
 pixel
   read fails, exercising GRFP_111 end to end.

 Verified with the GDAL unit suite (OK (66 tests)) in the ubuntu22 Debug
 container.

 Note: the GDAL provider's Windows message project
 (RFPMessage.vcproj/.vcxproj)
 has only ever merged the static RC template, so its message table has
 always
 been empty for this provider; the new text still reaches Windows clients
 because the default strings passed to the NlsMsgGet* calls were updated in
 step. Wiring it up like the other providers is left for a separate change.

 Fixes #1001
 }}}
-- 
Ticket URL: <https://trac.osgeo.org/fdo/ticket/1001#comment:2>
FDO <http://fdo.osgeo.org/>
Feature Data Objects