octave-maintainers
[Top][All Lists]
Advanced

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

Re: Better approach to gripes?


From: Rik
Subject: Re: Better approach to gripes?
Date: Sat, 2 Jan 2016 12:59:54 -0800

On 01/02/2016 12:09 PM, John W. Eaton wrote:
> On 01/02/2016 10:54 AM, Rik wrote:
>
>> 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.
>
> Yes, I think we should simplify these functions and eliminate the ones
> that aren't used.  You might check the Octave Forge code to make sure
> these other cases aren't used there either.

Is there an easy way to grep through the Octave Forge code without
downloading all the individual packages?  I do very little with the
packages and don't maintain a local copy.

>
> I added these functions in an attempt to keep the error messages
> consistent.  If some of them are only used a few times it may not make
> that much sense to have them.
>

I think that's correct.  Anything used more than 3 or 4 times should
probably be a function.

> If you want to distinguish warning/error with things like croak and carp
> then maybe we should keep the old names.  We can deprecate and schedule
> them for removal, but at least give people some warning.  I'm not really
> fond of the carp and croak names, but gripe isn't really great either.

I wasn't actually suggesting the same names, just the approach.  Since
you're okay with the strategy, I'll throw it open to the Octave Maintainers
list to decide.

I see two simple choices

1) Stay with gripe for error messages.  Move to a complimentary verb such
as "grumble", "whine", or "squawk" for messages that only result in a
warning.  This is kind of fun, but harder for non-native English speakers.

2)  Move to new descriptive, but boring, function names.  Maybe errmsg()
and warnmsg()?

--Rik



reply via email to

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