[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.net.iso vect

[Huidae Cho]

Martin,

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
would be to have Vect*2 routines that call fatal error and let the
developer decide which version to use. Some low level routines mix -1
return and fatal error on failure, which I think should be fixed.

Simply calling fatal error and terminating the process may not be a good
idea in some case where  many leftover files need to be deleted. I believe
at some point we need to standardize error handling.

I found an interesting discussion at
http://lists.osgeo.org/pipermail/grass-dev/2013-April/062938.html and think
you had similar concerns as mine here. I'm with Markus M that the warnings
in Vect_open routines somehow deserve a fatal error, but I believe that you
changed fatal errors to warnings to handle exception cases, which is
exactly what I did. Those modules had not been updated to reflect your
changes. But still I agree that we need a better way to handle opening
errors.

Regards,
Huidae
On May 4, 2014 3:58 AM, "Martin Landa" <landa.martin at gmail.com> wrote:

> Hi,
>
> 2014-05-03 15:49 GMT+02:00  <svn_grass at osgeo.org>:
> > Author: hcho
> > Date: 2014-05-03 06:49:33 -0700 (Sat, 03 May 2014)
> > New Revision: 60054
>
> I would say that such invasive changes should be discussed in advance.
> Now the vector library goes in different direction that raster library
> which promote fatal error even if raster map not found so the raster
> modules don't check return code of Rast_open_old() at all. Even this
> function has still integer return type. I am not fun of calling
> G_fatal_error() on such places. But we need to keep some consistency
> and to define rules when call G_fatal_error() and when G_warning() +
> error return code is preferable (and then to update alll modules to
> check the return code).
>
> Martin
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140504/f5201799/attachment.html>