octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Better approach to gripes?


From: Rik
Subject: Better approach to gripes?
Date: Sat, 2 Jan 2016 07:54:26 -0800

1/2/16

jwe,

I recently (cset 6176560b03d9) removed useless statements after gripe_XXX
calls which do not return to the calling function.  One of the things that
made this more difficult is that there are three types of gripe routines.

1) gripes which call error()
2) gripes which call warning()
3) gripes which decide at runtime based on an input argument whether to
call error() or warning()

The first two cases are fixed at compile time, but in order to split the
two categories I had to read the code for each function in gripes.cc and
make a list of who was naughty and nice.  Oops, I mean which called error
and which called warning.  This is tedious.  Other languages have addressed
this by splitting the names of the functions.  In Perl, for instance,
croak() emits a message and exits while carp() emits a message and
continues.  Maybe we need something similar for Octave so a programmer can
tell immediately whether the code is correct (correct with respect to
unreachable instructions after the function call).

The run-time case is even harder.  We can't add a NORETURN attribute
because the function might or might not return.  On the other hand, from a
practical perspective there are only two functions that appear to use this:
gripe_empty_arg and gripe_wrong_type_arg.  gripe_empty_arg is never used in
the code without setting is_error false so this case could be reduced to a
case 2 gripe which calls warning.  gripe_wrong_type_arg is never used with
the third is_error argument so by default this will always produce an
error.  This could be reduced to a case 1 gripe which calls error.

Thoughts,
Rik





reply via email to

[Prev in Thread] Current Thread [Next in Thread]