Martin, Even after defining error handlers, we still need to call G_fatal_error to trigger them. The Vect_set_error_handler_io manual recommends to use this routine after Vect_open_old* because it needs the point to In and Out, but if Vect_open_old* fails and doesn't call G_fatal_error, at what point, can we call fatal error without checking their return value?
G_add_error_handler is a good way to do a cleanup, but, IMHO, it doesn't eliminate the need for checking Vect_open_* return value completely because of the above reason as long as they don't call G_fatal_error internally. But again, when they call fatal error internally, they don't have pointers to maps. It would be great if we could keep track of opened raster/vector maps and properly close existing maps and delete unfinished new maps inside G_fatal_error. And use G_add_error_handler to do a non-map related cleanup. Huidae On Sun, May 4, 2014 at 2:52 PM, Martin Landa <landa.mar...@gmail.com> wrote: > Hi, > > 2014-05-04 16:16 GMT+02:00 Huidae Cho <gras...@gmail.com>: > > I agree that it's not fun to call fatal error whenever opening > something, so > > I thought about adding fatal error in Vect routines. But some modules > > actually check its return value and do cleaning before exit. Another > option > > please note that cleaning should be implemented as error handlers [1], > vector [2] and db [3] libs have defined standardized (often used) > error handlers. Martin > > [1] > http://grass.osgeo.org/programming7/gis_2handler_8c.html#aa01633c78dd9561c740e4a89e33ad80c > [2] > http://grass.osgeo.org/programming7/vector_2Vlib_2handler_8c.html#aa692177b1d99fdcb7c982b8a64889263 > [3] > http://grass.osgeo.org/programming7/db_2dbmi__client_2handler_8c.html#a67d9435f4187f1119e1a29b60efdb71b >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev