[GRASS-dev] [GRASS-SVN] r60054 - in grass/trunk: display/d.extract display/d.path display/d.vect.chart general/manage/lister lib/sites lib/vector/Vlib ps/ps.map raster/r.carve raster/r.contour raster/r.le/r.le.setup raster/r.random raster/r.stream.extract raster/r.stream.order raster/r.stream.segment raster/r.stream.snap raster/r.to.vect raster/r.volume raster/simwe/simlib vector/v.buffer vector/v.build vector/v.build.polylines vector/v.class vector/v.clean vector/v.clean/test vector/v.colors vector/v.colors.out vector/v.db.connect vector/v.db.select vector/v.delaunay vector/v.distance vector/v.drape vector/v.edit vector/v.external vector/v.extract vector/v.extrude vector/v.in.ascii vector/v.in.db vector/v.in.dwg vector/v.in.lidar vector/v.in.ogr vector/v.in.region vector/v.in.sites vector/v.kernel vector/v.label vector/v.label.sa vector/v.lrs/v.lrs.create vector/v.lrs/v.lrs.label vector/v.lrs/v.lrs.segment vector/v.lrs/v.lrs.where vector/v.neighbors vector/v.net.alloc vector/v.n

[Huidae Cho]

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.martin at gmail.com> wrote:

> Hi,
>
> 2014-05-04 16:16 GMT+02:00 Huidae Cho <grass4u at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140504/5ece91c4/attachment.html>