Yann Chemin wrote:

> some confusion you may clarify.
> 
> Looking into some v6 to v7 coding translation, how would you test for
> readability of raster cell header in v7
> 
> <from grass-addons: i.landsat.toar>
> 
>           mapset = G_find_cell2(band_in, "");
>           if (mapset == NULL) {
>               G_warning(_("Raster map <%s> not found"), band_in);
>               continue;
>           }
>           if ((infd = G_open_cell_old(band_in, mapset)) < 0)
>               G_fatal_error(_("Unable to open raster map <%s>"), band_in);
>           if (G_get_cellhd(band_in, mapset, &cellhd) < 0)
>               G_fatal_error(_("Unable to read header of raster map <%s>"), 
> band_in);
>           if (G_set_window(&cellhd) < 0)
>               G_fatal_error(_("Cannot reset current region"));
> 
> The Last 4 lines I am trying to see if Rast_get_cellhd should be used...
> 
>             if (Rast_get_cellhd(band_in, "", &cellhd) < 0)
>                 G_fatal_error(_("Unable to read header of raster map <%s>"), 
> band_in);
>             if (G_set_window(&cellhd) < 0)
>                 G_fatal_error(_("Cannot reset current region"));
> 
> These 4 lines above are returning errors because the two functions
> Rast_get_cellhd and G_set_window both return void, and they are tested
> for a return value.
> 
> How would you rewrite that initial code within version 7?

Remove the test. If a 6.x function returned a status and the 7.x
version doesn't return anything, it means that the 7.x version calls
G_fatal_error() itself.

I made this change for almost every lib/raster function where the only
consequence of an error return was to call G_fatal_error() (assuming
that the code bothered to check the return value in the first place).

Also, note that Rast_open_* will only ever return a valid descriptor. 
If something goes wrong, it results in a fatal error, so there's no
point in explicitly checking for "fd < 0".

Functions which read metadata files which may or may not exist
(categories, colour tables, etc) still return status codes.

-- 
Glynn Clements <[email protected]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to