Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Mechanism to generate annotated "error codes"

Reply
Thread Tools

Mechanism to generate annotated "error codes"

 
 
Don Y
Guest
Posts: n/a
 
      03-02-2012
Hi Shao,

On 3/1/2012 11:50 PM, Shao Miller wrote:
> On 3/2/2012 01:05, Don Y wrote:
>>
>>> However, it's possible that you've already considered and dismissed
>>> material akin to this response post's content.

>>
>> <grin> I've tried to think hard about the sorts of housekeeping
>> to which any *manual* system would be vulnerable. Since I am
>> operating in a rather "flush" environment, I am planning on
>> using those resources to make the code and user interfaces
>> more robust and full-featured.

>
> Just out of curiosity, did you skip over the 's_status' part of my
> previous response, or dismiss it as Not The Right Strategy For You?


I'm trying to avoid complicating the discussion with the introduction
of mechanisms of passing "qualifying information" (what you call
"extended status information") up to the caller. This is a whole
'nother can of worms as each potential error/result could potentially
have its own idea as to "what's important/pertinent".

My current approach just focuses on indicating *where* the "test
failed" and in which context that was encountered.

E.g., imagine someone says the application wasn't accepting their
"input" (cf the "get value" example). People are notoriously
inaccurate at telling you the *exact* message that they are
receiving:
"I typed in my age but it said the number I typed was bad"
"No, I'm sure it didn't say that (because I *know* what all of
the error messages are and none of them are 'the number was bad')"
"Well, that's what it *meant*! I can't remember the actual WORDING..."
"Could you do whatever it was you were doing and provide me with
the error identifier located at the end of the message?"
"OK, it says _______"
"Ah, you've just typed in a '-' sign but you did so after you
started typing in the numeric value/digits. If you want the value
to be negative, you need to type the '-' sign first. OTOH, if you
are trying to type '2012-1965' and hoping the machine will interpret
that as 47, I'm sorry but the machine doesn't have that capability..."

I'm not worried (in this discussion) about providing the extra
details (e.g., "2012-1965") to better explain/understand the
nature of the error to that finer degree.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      03-02-2012
Don Y <(E-Mail Removed)> writes:
[...]
> You need to maintain this "by hand". There is nothing that
> prevents you from:
> #define YES (2)
> #define NO (2)
>
> Nor:
> #define YES (2)
> ...
> #define ABSOLUTELY (27)
> (assuming yes and absolutely are synonyms)

[...]

A minor point: parenthesizing macro definitions is a good habit, but
it's not necessary when the macro expands to a single token. This:

#define ABSOLUTELY 27

is just as safe as

#define ABSOLUTELY (27)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      03-02-2012
On 2012-03-02, Keith Thompson <(E-Mail Removed)> wrote:
> Don Y <(E-Mail Removed)> writes:
> [...]
>> You need to maintain this "by hand". There is nothing that
>> prevents you from:
>> #define YES (2)
>> #define NO (2)
>>
>> Nor:
>> #define YES (2)
>> ...
>> #define ABSOLUTELY (27)
>> (assuming yes and absolutely are synonyms)

> [...]
>
> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token. This:
>
> #define ABSOLUTELY 27
>
> is just as safe as
>
> #define ABSOLUTELY (27)


Safer. The former ABSOLUTELY above can be subject to token pasting.

#define XPASTE(X, Y) X ## Y
#define PASTE(X, Y) XPASTE(X, Y)

PASTE(FOO_, ABSOLUTELY) /* result: FOO_27 */

If ABSOLUTELY is (27) then the above is undefined behavior, since
pasting FOO_ with ( is an invalid token.

I.e. #define ABSOLUTELY 27 is, effectively, not only a constant expression
evaluating to 27, but it is lexically a numeric token, which can be desireable.
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      03-02-2012
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>Don Y <(E-Mail Removed)> writes:
>[...]
>> You need to maintain this "by hand". There is nothing that
>> prevents you from:
>> #define YES (2)
>> #define NO (2)
>>
>> Nor:
>> #define YES (2)
>> ...
>> #define ABSOLUTELY (27)
>> (assuming yes and absolutely are synonyms)

>[...]
>
>A minor point: parenthesizing macro definitions is a good habit, but
>it's not necessary when the macro expands to a single token. This:
>
> #define ABSOLUTELY 27
>
>is just as safe as
>
> #define ABSOLUTELY (27)


Much as I hate to disagree with Leader Kiki, I have to take exception to
this. If there is a corporate requirement that all macro definitions be
parenthesized, as is probably the case in many workplaces, then not
parenthesizing exposes the coder to the risk of ending up on the
unemployment line.

Hardly safe by my lights...

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      03-02-2012
Hi Keith,

On 3/2/2012 3:05 AM, Keith Thompson wrote:

> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token. This:


Keeping a gun's safety "on" is "a good habit". Do you often
leave it *off* just because you don't *think* you need it
"on" at the present time? Or, do you wait until you
really *need* it "off" (i.e., just prior to discharge)?

Good habits are kept -- as a matter of HABIT! :>
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      03-02-2012
On 03/02/2012 12:46 PM, Don Y wrote:
> Hi Keith,
>
> On 3/2/2012 3:05 AM, Keith Thompson wrote:
>
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token. This:

>
> Keeping a gun's safety "on" is "a good habit". Do you often
> leave it *off* just because you don't *think* you need it
> "on" at the present time? Or, do you wait until you
> really *need* it "off" (i.e., just prior to discharge)?
>
> Good habits are kept -- as a matter of HABIT! :>


I check my keys every time I go out the door of my house, as a matter of
habit, even if I don't intend to lock the door. That's a good habit.
People with OCD might check their keys each time they go out the bedroom
door, even if it doesn't have a lock. That's not a good habit, that's a
waste of time. In extreme cases, people with OCD waste so much time
checking things that don't need to be checked, that they never get
anything useful done with their life.

Parentheses convert other kinds of expressions into primary expressions.
Macro expansions that are already primary expressions (identifiers,
constants, string literals, and generic selections* - 6.5.1) - don't
need parentheses. Parenthesizing them is closer to the OCD end of the
spectrum, than to the good habit end.

*Generic selections are a new feature of C2011.
 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      03-02-2012
Hi James,

On 3/2/2012 12:08 PM, James Kuyper wrote:

>>> A minor point: parenthesizing macro definitions is a good habit, but
>>> it's not necessary when the macro expands to a single token. This:

>>
>> Keeping a gun's safety "on" is "a good habit". Do you often
>> leave it *off* just because you don't *think* you need it
>> "on" at the present time? Or, do you wait until you
>> really *need* it "off" (i.e., just prior to discharge)?
>>
>> Good habits are kept -- as a matter of HABIT! :>

>
> I check my keys every time I go out the door of my house, as a matter of
> habit, even if I don't intend to lock the door. That's a good habit.
> People with OCD might check their keys each time they go out the bedroom
> door, even if it doesn't have a lock. That's not a good habit, that's a
> waste of time. In extreme cases, people with OCD waste so much time
> checking things that don't need to be checked, that they never get
> anything useful done with their life.


OCD interferes with your goal -- "living".

> Parentheses convert other kinds of expressions into primary expressions.
> Macro expansions that are already primary expressions (identifiers,
> constants, string literals, and generic selections* - 6.5.1) - don't
> need parentheses. Parenthesizing them is closer to the OCD end of the
> spectrum, than to the good habit end.


I guess I don't see two extra keystrokes on a #define as interfering
with my goal (of writing reliable code that others can maintain).
I've already invested 10 keystrokes ("#define " the whitespace between
the symbol and its definition and the trailing '\n') and will invest
at least 2 more (assuming the symbol and definition are each just 1).
Increasing that "overhead" from 12 to 14 is pocket change.

OTOH, I can't count the number of times I've had to step in and
"fix" someone's "minor tweek" of a running program when they
changed:
#define PHONE_NUMBER_DIGITS 7
to:
#define PHONE_NUMBER_DIGITS 3+7
And then have to *explain* the reason behind the *need* for the parens:
"So, if I just said '10', instead, I wouldn't have had the problem
AND wouldn't have had to type the parens? I guess I should just
type '10' in the future..."
"No, the problem with *that*, is..."

I can't speak for you but *I* sure don't like wasting my time on
that sort of after-the-fact annoyance.

Of course, you're free to live with whatever coding style you
(and your clients/employers) find suitable for the projects
and personnel available to you.

You could also build giant tables of #define's to represent all
of the possible error codes that routines in your project can
throw! :>

[I'd really prefer to address the subject of my OP. Missing the
forest for the trees is a sure-fire "waste of time" :>]
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      03-02-2012
On 2012-03-02, Don Y <(E-Mail Removed)> wrote:
> Hi Keith,
>
> On 3/2/2012 3:05 AM, Keith Thompson wrote:
>
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token. This:

>
> Keeping a gun's safety "on" is "a good habit". Do you often
> leave it *off* just because you don't *think* you need it
> "on" at the present time? Or, do you wait until you
> really *need* it "off" (i.e., just prior to discharge)?


Do you often modify your gun to a completely different model,
and without touching the safety switch?
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-02-2012
On 03/ 2/12 11:05 PM, Keith Thompson wrote:
> Don Y<(E-Mail Removed)> writes:
> [...]
>> You need to maintain this "by hand". There is nothing that
>> prevents you from:
>> #define YES (2)
>> #define NO (2)
>>
>> Nor:
>> #define YES (2)
>> ...
>> #define ABSOLUTELY (27)
>> (assuming yes and absolutely are synonyms)

> [...]
>
> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token. This:
>
> #define ABSOLUTELY 27
>
> is just as safe as
>
> #define ABSOLUTELY (27)


Or simply don't use macros for constants!

--
Ian Collins
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      03-02-2012
Keith Thompson <(E-Mail Removed)> writes:

> Don Y <(E-Mail Removed)> writes:
> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token. This:
>
> #define ABSOLUTELY 27
>
> is just as safe as
>
> #define ABSOLUTELY (27)


Furthermore,

#define PRIx64 "llx"

is far more useful than

#define PRIx64 ("llx")
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A portable LISP interpreter that includes all the majorlist-processing functions is described. A complete, annotated listing of theprogram's code, written in PASCAL, is included. Emmy Noether C Programming 5 08-05-2010 04:31 PM
A portable LISP interpreter that includes all the majorlist-processing functions is described. A complete, annotated listing of theprogram's code, written in PASCAL, is included. Emmy Noether Python 6 08-05-2010 04:31 PM
Can decorator syntax do this ? (annotated results' names) Sakesun Roykiattisak Python 1 08-05-2004 02:06 PM
The Annotated C++ Language Standard by Koenig & Stroustrup???? Steven T. Hatton C++ 6 04-12-2004 06:05 AM



Advertisments