Hi,
I need G_error (function that does the same thing as G_fatal_error except that it does not exit). Any objections to me adding it (as soon as I get my CVS working again)? I think it can be good to have a possibility of issuing an error message that doesn't call exit.
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
Wolf Bergenheim wrote:
I need G_error (function that does the same thing as G_fatal_error except
that it does not exit). Any objections to me adding it (as soon as I get
my CVS working again)? I think it can be good to have a possibility of
issuing an error message that doesn't call exit.
That's essentially what G_warning() does.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 6 Jun 2006, Glynn Clements wrote:
Wolf Bergenheim wrote:
I need G_error (function that does the same thing as G_fatal_error except
that it does not exit). Any objections to me adding it (as soon as I get
my CVS working again)? I think it can be good to have a possibility of
issuing an error message that doesn't call exit.That's essentially what G_warning() does.
Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (;
--W
--
<:3 )---- Wolf Bergenheim ----( 8:>
Wolf:
>> I need G_error (function that does the same thing as G_fatal_error
>> except that it does not exit). Any objections to me adding it (as
>> soon as I get my CVS working again)? I think it can be good to have
>> a possibility of issuing an error message that doesn't call exit.
Glynn:
> That's essentially what G_warning() does.
>
Wolf:
Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (;
So what's wrong with "WARNING:" ? what's the situation?
what about: G_message("ERROR: zombies");
If it must happen, perhaps it should be called G_nonfatal_error() or
something more explicit than G_error()?
Hamish
On Tue, 6 Jun 2006, Hamish wrote:
Wolf:
I need G_error (function that does the same thing as G_fatal_error
except that it does not exit). Any objections to me adding it (as
soon as I get my CVS working again)? I think it can be good to have
a possibility of issuing an error message that doesn't call exit.Glynn:
That's essentially what G_warning() does.
Wolf:
Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (;
So what's wrong with "WARNING:" ? what's the situation?
It is a fatal error but I can not use G_fatal_error because it calls exit, and I need to properly close the vector in v.edit. One such case is for instance that the DB connection fails. I still need to build the topology or else the vector file is broken (need to run v.build on it before you can continue).
what about: G_message("ERROR: zombies");
Doesn't do the ERROR or WARN magic (like email etc.), and it doesn't beep 
If it must happen, perhaps it should be called G_nonfatal_error() or
something more explicit than G_error()?
If you have G_error and G_fatal_error and both are documented, then it would be quite clear which does what? But if you like G_nonfatal_error better then I can live with it too. I don't really care that much about the function name, but I do care what it does (;
--W
--
<:3 )---- Wolf Bergenheim ----( 8:>
Wolf:
>>>> I need G_error (function that does the same thing as
>>>> G_fatal_error except that it does not exit). Any objections to me
>>>> adding it (as soon as I get my CVS working again)? I think it can
>>>> be good to have a possibility of issuing an error message that
>>>> doesn't call exit.
Glynn:
>>> That's essentially what G_warning() does.
>>>
Wolf:
>> Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (;
Hamish:
> So what's wrong with "WARNING:" ? what's the situation?
Wolf:
It is a fatal error but I can not use G_fatal_error because it calls
exit, and I need to properly close the vector in v.edit. One such
case is for instance that the DB connection fails. I still need to
build the topology or else the vector file is broken (need to run
v.build on it before you can continue).
so when you detect an error call a cleanup function to sort out the
mess, and have G_fatal_error() as the fn's last line?
Hamish
On Tue, 6 Jun 2006, Hamish wrote:
so when you detect an error call a cleanup function to sort out the
mess, and have G_fatal_error() as the fn's last line?
Thing is I wanted to avoid making a cleanup function that takes an ellipsis (; but I guess I have no choice d:
--W
--
<:3 )---- Wolf Bergenheim ----( 8:>
On Tue, 6 Jun 2006, Wolf Bergenheim wrote:
On Tue, 6 Jun 2006, Hamish wrote:
> Wolf:
>>>> I need G_error (function that does the same thing as G_fatal_error
>>>> except that it does not exit). Any objections to me adding it (as
>>>> soon as I get my CVS working again)? I think it can be good to have
>>>> a possibility of issuing an error message that doesn't call exit.
> Glynn:
>>> That's essentially what G_warning() does.
>>>
> Wolf:
>> Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (;
>
>
> So what's wrong with "WARNING:" ? what's the situation?
>It is a fatal error but I can not use G_fatal_error because it calls exit,
and I need to properly close the vector in v.edit. One such case is for
instance that the DB connection fails. I still need to build the topology
or else the vector file is broken (need to run v.build on it before you
can continue).
In the orginal GRASS 5 compiled R interface, the error handling is passed
to R for exactly this reason to avoid exit(). Then it was:
void R_G_init(char *name) {
G_set_error_routine(R_handler);
G_sleep_on_error(0);
G_gisinit(name);
}
int R_handler(char *message, int fatal) {
if(fatal == 1) error(message);
else warning(message);
return(1);
}
where R_G_init() simply sets up the handler and the handler lets you set
the appropriate actions. This of course assumes that your function does
the clear-up, but G_set_error_routine() certainly worked very nicely in
the 5.* codebase except where gislib functions called exit() directly -
this was cleaned later I think by Radim. It is still in current CVS
lib/gis, so I'd try it first, because it will also grab both GRASS errors
and warnings thrown by GRASS functions your code calls.
Roger
> what about: G_message("ERROR: zombies");
>Doesn't do the ERROR or WARN magic (like email etc.), and it doesn't beep
>
> If it must happen, perhaps it should be called G_nonfatal_error() or
> something more explicit than G_error()?
>If you have G_error and G_fatal_error and both are documented, then it
would be quite clear which does what? But if you like G_nonfatal_error
better then I can live with it too. I don't really care that much about
the function name, but I do care what it does (;--W
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no
On Tue, 2006-06-06 at 08:51 +0100, Glynn Clements wrote:
Wolf Bergenheim wrote:
> I need G_error (function that does the same thing as G_fatal_error except
> that it does not exit). Any objections to me adding it (as soon as I get
> my CVS working again)? I think it can be good to have a possibility of
> issuing an error message that doesn't call exit.That's essentially what G_warning() does.
There's always G_set_error_routine()...
--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785