[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