On Sun, Apr 7, 2013 at 11:21 AM, Martin Landa <[email protected]> wrote: > Hi, > > 2013/4/6 Markus Metz <[email protected]>: >>> These defines are used by a few functions, eg. >>> G_check_input_output_name(). Other candidates could eg. >>> Vect_open_old() and similar functions (eg. call G__error() when vector >>> map is not found). I would suggest to add G__error() and >>> G__set_error_code() just for internal use (see the attached path). >> >> What's your motivation for adding G__error() and G__set_error_code()? >> Are there problems with e.g. Vect_open_old()? > > first of all, G_FATAL_EXIT|PRINT|RETURN codes exist in libgis for a > long time. Some functions use them as an argument. In raster library > Rast_open_old() calls G_fatal_error() when raster map is not found. > Currently Vect_open_old() calls G_warning() and return -1. Some vector > modules do not check return code of Vect_open_old().
Previous to r49405, Vect_open_old() called G_fatal_error() by default, therefore there was no need to check if Vect_open_old() failed. Vector modules were not updated for the changes introduced with r49405. > My idea was to > call G__error() when vector map is not found. Then the program would > terminate if `err_code` in `error.c` is G_FATAL_EXIT. Otherwise > message would be printed out (G_FATAL_PRINT) or the function would > finish just with return code without printing any message > (G_FATAL_RETURN). Similarly to G_check_input_output(), adding > G__error() and G__set_error_code() would also avoid adding extra > arguments to these functions. Why not just use G_fatal_error() like Rast_open_old()? Why this more complicated G_FATAL_EXIT|PRINT|RETURN? BTW, you changed some G_fatal_error() to G_warning(), particularly for Vect_write_line() and Vect_delete_line(). Consequently, the return values need now be checked whenever these functions are called (very often). IMHO, it is worth a fatal error if Vect_write_line() or Vect_delete_line() fail. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
