[GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[Radim Blazek]

Thanks for the suggestion. The title of
http://trac.osgeo.org/qgis/ticket/1878 is however "remove
setjmp/longjmp in grass plugin&provider and use exceptions instead" so
the intention was to remove setjmp/longjmp.
I don't know exactly if there were problems with setjmp/longjmp or it
was just attempt to improve the code. Using exceptions is certainly
better.

Radim

On Thu, Jan 14, 2010 at 4:59 PM, Soeren Gebbert
<soerengebbert at googlemail.com> wrote:
> I use in vtk.grass-bridge (C++ -VTK GRASS wrapper) a different approach.
> http://code.google.com/p/vtk-grass-bridge/
>
> Replacing the G_fatal_error() function and using the setjmp/longjmp
> construct allows you to catch all errors from grass, inclusively stack
> restoration. Glynn made this suggestion. :)
>
> This function replace G_fatal_error(), to set with
> G_set_error_routine(vgb_error_handler);:
>
> int vgb_error_handler(const char *msg, int fatal)
> {
>    if (fatal == 0)
>    {
>        fprintf(stderr, "%s\n", msg);
>        return 1;
>    }
>    else
>    {
>        fprintf(stderr, "\n############## Exceptiont called ###########\n");
>        vgb_error_message = msg;
>        longjmp(vgb_stack_buffer, 1);
>    }
>    return 1;
> }
>
>
> This is an example how to handle fatal errors (old example, still
> check for return value):
>    if (!setjmp(vgb_stack_buffer))
>    {
>        if (Rast_get_row(this->Map, this->RasterBuff, idx, this->MapType) < 0)
>        {
>            error = 1;
>        }
>    }
>    else
>    {
>        this->InsertNextError(vgb_error_message);
>        return NULL;
>    }
>
> Code examples from:
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSDefines.h
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSInit.cxx
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster/vtkGRASSRasterMapBase.cxx
>
> Soeren
>
>
> 2010/1/14 GRASS GIS <trac at osgeo.org>:
>> #869: Compile libs with -fexception
>> --------------------------+-------------------------------------------------
>>  Reporter:  rblazek      |       Owner:  grass-dev at lists.osgeo.org
>>      Type:  defect       |      Status:  closed
>>  Priority:  normal       |   Milestone:  6.5.0
>>  Component:  Compiling    |     Version:  unspecified
>> Resolution:  worksforme   |    Keywords:
>>  Platform:  Unspecified  |         Cpu:  All
>> --------------------------+-------------------------------------------------
>> Comment (by rblazek):
>>
>>  Replying to [comment:8 hamish]:
>>  > fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
>>  >
>>  {{{
>>  This would be required for any C library linked by Qgis. This is out of
>>  discussion.
>>  Qgis has to manage correctly C libraries by providing wrappers to raise
>>  execeptions
>>  when C calls fail, else people will start asking that libc too supports
>>  exceptions, soon or later...
>>  }}}
>>
>>  Probably he does not know, that GRASS libraries can call exit(). No
>>  wrapper can help in that situation AFAIK.
>>
>> --
>> Ticket URL: <https://trac.osgeo.org/grass/ticket/869#comment:9>
>> GRASS GIS <http://grass.osgeo.org>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>