<p dir="ltr">Glynn,</p>
<p dir="ltr">I agree with you that Vect_open needs to call fatal error just like Rast_open because there would be nothing to do *except* cleaning garbage when opening fails. Some modules actually delete temp files before quitting and <a href="http://lists.osgeo.org/pipermail/grass-dev/2013-April/062938.html">http://lists.osgeo.org/pipermail/grass-dev/2013-April/062938.html</a> this discussion may be just for that, I think. </p>
<p dir="ltr">BTW, I don't see Rast_open_old returning a negative value on failure as documented in the developer's manual. If this is clearly documented and fatal error is also mentioned, it would save unnecessary conditional checks against Rast_open_old. </p>
<p dir="ltr">Just my 2 cents. <br>
Huidae</p>
<div class="gmail_quote">On May 4, 2014 3:23 AM, "Glynn Clements" <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Huidae Cho wrote:<br>
<br>
> OK, I did a quick search and there are 104 calls to Vect_open_new. 63 calls<br>
> don't check its return value and 41 calls check.<br>
<br>
This is the main reason why I replaced status returns with fatal<br>
errors in much of lib/raster and lib/gis (r40209, r40217, r40701).<br>
<br>
I propose that lib/vector takes the same approach (I didn't touch<br>
lib/vector at the time because I'm not that familiar with it, and was<br>
unsure as to its stability).<br>
<br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</blockquote></div>