Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Mechanism to generate annotated "error codes" |
| Date | 2012-03-03 19:15 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <jiuj7v$uam$1@speranza.aioe.org> (permalink) |
| References | <jiojq3$3cm$1@speranza.aioe.org> <error-codes-20120302005428-Supersedes@ram.dialup.fu-berlin.de> <jipsv0$rkd$1@speranza.aioe.org> <error-messages-20120303033550@ram.dialup.fu-berlin.de> |
Hi Stefan,
On 3/2/2012 8:05 PM, Stefan Ram wrote:
> Don Y<this@isnotme.com> writes:
>> You need to maintain this "by hand". There is nothing that
>> prevents you from:
>> #define YES (2)
>> #define NO (2)
>
> The include-file can be generated:
>
> printf( "#define YES (%d)\n", ++i );
Sure! But how do you know "YES" is ever USED anywhere?
(replace YES with MOTOR_OVERHEATED and every other
"error" condition that this file IMPLIES exists)
Also, you have now created a dependency that "every"
file relies upon. Add a new error code and every file
that #includes "errorcodes.h" has to be recompiled.
You also tempt people to do things like:
/* errors generated by get_value() */
#define TOO_MANY_DECIMAL_POINTS (27)
#define MISSING_SIGN (28)
#define LOST_PRECISION (29)
/* errors generated by run_motor() */
...
if ( (error >= TOO_MANY_DECIMAL_POINTS)
&& (error <= LOST_PRECISION) ) {
// this must be an error propagated up from get_value()
So, if you later add a TOO_MANY_SIGNS error code, you risk
breaking this code (which should never have existed in the
first place). Error codes aren't "numbers" that can be
manipulated as such. They have no relationships to each
other.
>> There is nothing that ensures:
>> #define TOO_MANY_DIGITS (375)
>> is actually *used* anywhere!
>
> This is a kind of library. When you defined anything (say, a
> function) in a library, you can never know whether the
> client really uses it.
In *my* scheme, errors that are never signaled magically disappear
from the "error space" -- just like opting not to link in a
routine from a library.
>> You have to maintain one such table for each library/subsystem
>> (having one for the entire application is just silly -- if it
>> has to be maintained by hand!)
>
> I only see two extremes: Either maintain one table per
> function (which I do), or one global table for all your
> code (like Microsofts HRESULTs, see
>
> http://source.winehq.org/source/include/winerror.h
>
> ). You seem to prefer some kind of mixture: one table
> per subsystem. This is confusing since now merging, splitting
> or changing subsystem boundaries will become more difficult,
> because one also needs to adjust this table each time.
You have those problems IF YOU WANT TO MAINTAIN THAT TABLE!
*I* don't have "that table"! :>
>> And, if you have multiple such tables, you have to ensure the
>> "number spaces" for each do not overlap.
>
> If you do not want them to overlap, then you have
> effectively one single global table per programmer (=Don Y).
No. No table. Period.
> What happens when you join another programmer or
> organization for a project? Will they agree to use your
> table? Will they force you to use their error-code
> convention?
That's a management issue. Another programmer joins your team.
Does your Management insist on coding standards and procedures?
If not, then, "Hey, this is how *my* code reports errors. I
don't really care how *yours* does -- except to the extent
that I use yours. Demonstrate how your scheme handles these
issues and I'll show you how MINE does..."
>> How do you find which errors are thrown by each module/library/etc.?
>
> grep?
Sure. So you examine the entire source tree each time you
want to locate the source of an error? How do you guarantee
that get_isbn_number() doesn't use "TOO_MANY_DECIMAL_POINTS"
to indicate a malformed ISBN? What do you use to find error
code "instances" in the source tree? Is "TOO_MANY_POTATOES"
an error code?
>> How do you ensure you don't already have "OVERFLOW_DOUBLE" hidden
>> away in that SINGLE long list of error codes?
>
> You add tags in comments
>
> #define OVERFLOW_DOUBLE 2 /* tag:numeric tag:iserror */
>
> Then you can find all numeric error codes with grep.
Again, you are having to do this MANUALLY. I'm sorry but *I*
am not infallible :> And, most of the folks I've worked with
are no better than me!
>> No! That's what leads to "bad value" type error messages!
>
> If it is programmed in this way.
>
>> The application doesn't want to be concerned with the details of
>> "what makes a particular input string a valid numeric indicator".
>> It wants to *bury* that information and those criteria inside
>> a tool that it then *uses* to perform that operation for it.
>
> Such a tool cannot know the domain vocabulary of the
> application.
The tool doesn't have to know the vocabulary. It provides a means
for the *developer* to write the messages. All it does is bind
error codes to messages, ensure that those error codes are
unique, indicates where each is raised in the source tree and
give a handle to this information back to the devloper (and
the code he writes)
> Usually, an application calls a library function, which
> returns application-domain independent error codes. The
> application then translates these into error messages which
> use the language (domain vocabulary and natural language)
> of the user of the application.
Exactly. As you move up the abstraction hierarchy, you apply
more context to your messages. "Bad value" becomes "Bad house
number" (as in a street address). The advantage is that an
upper layer of abstraction can get a description of the
exact nature of the "problem" instead of just treating it as
a "bad number" (what, specifically, *makes* it a "bad number"?)
>> Should the UI be responsible for identifying the reason why
>> keystrokes are not available from the "keyboard device"? That
>> would imply that the UI would need to know *how* the keyboard
>> device works and the sorts of things that could go wrong with
>> it.
>
> When there are no keystrokes, it usually means that no one
> has pressed a key, which does not seem to be an error. The
> computer usually waits patiently.
Or the keyboard is unplugged. Or the pty connected to stdin
has disconnected. Or...
>> Likewise, should a function that gets the setpoint for a
>> temperature controller from the user know what the *actual*
>> syntax of a "valid temperature specification" is? And,
>> *how* the user erred in specifying that value?
>
> When the temperatur controller defines this syntax
> for its interface, it does not have to be the same syntax
> that is used in the user interface of the application.
The temperature is an *aspect* of the application (not a hardware
device, etc.). It would be silly to expect users to specify
temperatures using roman numerals when all other numeric values
are specified in decimal.
I.e., "get_value()" would tend to be an implicit part of the
design of the user interface. You wouldn't want the user to
learn different rules for different parts of the application.
> The application defines the syntax it expects from its
> user. It then checks this syntax reporting any errors
> to the user.
You don't *really* parse the user input, keystroke by keystroke,
in your main(), do you?? No atof(), strtod(), sscanf(), etc.?
> If there are no errors, it converts this
> syntax into whatever syntax the temperatur controller
> uses. (We do not want the user to learn a new application
> syntax, whenever the temperatur controller was exchanged.)
>
> If the temperature controller then reports any syntax
> errors, that's an error of the application programmer,
> not of the user.
>
>> The application *layer* that is responsible for this is
>> where the error can best be explained. Anything below that
>> doesn't have sufficient knowledge of *context* to explain
>> it meaningfully. Anything *above* that doesn't want to be
>> concerned with this level of detail (see above).
>
> I do not see anything above the application layer. The
> application is the highest layer that communicates directly
> with the user. It uses a layer below, which is the library
> layer.
There are *many* layers. Within libraries, between libraries,
within subsystems, between subsystems, etc. Any of these can
be designed to talk to the user.
E.g., main() calls OpenFileDialog() to get a filename from
the user. OpenFileDialog() is "communicating directly with the
user" -- yet it is NOT at the top/application layer!
>> And how does the person *using* the application that encapsulates
>> this code know what's gone wrong with his *use* of the application?
>
> It is the duty of the application to explain that to him.
>
>> filemove exposes the error from MoveFile to upper levels.
>
> No, it exposes its own codes. When they happen to be the
> same as the codes of a lower level, this is a coincidence.
> For example say:
>
> int f(){ return g(); }
>
> here, f returns its own codes, converting the codes it
> got from g, even if, in this special case, the conversion
> happens to be simple, because it is the identity function,
> by pure coincidence.
>
>> How do you explain the error to the user -- unless you
>> require MoveFile to be aware of all of the things that can
>> happen *inside* filemove?
>
> You have to translate them anyway, because all text
> messages of libraries usually use a specific natural
> language, say: English.
>
> Now, as we all know, users typically do not understand
> English but German. Well, whatever language they understand:
> The library does not need to know. A file-copy-library
> should have to know about natural languages.
>
> Yes, the application must translate each and every little error
> message into a language that the user understands, including
> his domain vocabulary. As they say:
>
> »Writing an application is a dirty job,
> but somebody's got to do it.«
No. All you have to do is get a suitable message to the user
accounting for L10N/I18N. The mechanism that you use to do this
is up to you.
I can use Literate Programming to prepare documentation in
French and English *alongside* the actual sources that I
am documenting. Just because you don't use that technique
doesn't mean others can't!
>> When filemove changes (possibly recognizing NEW error
>> conditions or *different* error conditions), then MoveFile
>> needs to be able to explain those new "problems" for the
>> user.
>> You haven't isolated the responsibilities.
>
> The uppermost level (= the application layer) has to explain
> the errors to the user.
Any level that deals with any (type of) user has to explain the
errors/results to that user. The LIBRARY has to explain its
results to the APPLICATION (using your terminology). In my
scheme, a layer can rely on its successive underlings for more
*specific*/detailed information about the error.
> When "filemove" is not part of the uppermost level, it does
> not have to do this, but might just return it specific numeric
> error codes according to its interface. But the uppermost
> level then needs to explain what happend to the user.
>
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 12:48 -0700
Re: Mechanism to generate annotated "error codes" Willem <willem@toad.stack.nl> - 2012-03-01 21:29 +0000
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 16:53 -0700
Re: Mechanism to generate annotated "error codes" William Ahern <william@wilbur.25thandClement.com> - 2012-03-01 14:13 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 22:07 -0700
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-01 17:53 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 23:05 -0700
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-02 01:50 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 00:43 -0700
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-03 17:58 -0500
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-04 03:16 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 13:47 -0700
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 13:45 -0700
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-04 18:37 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 22:12 -0700
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-08 01:41 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-09 14:34 -0700
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 00:30 -0700
Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-02 02:05 -0800
Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-02 10:47 +0000
Re: Mechanism to generate annotated "error codes" gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-02 14:18 +0000
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 10:46 -0700
Re: Mechanism to generate annotated "error codes" James Kuyper <jameskuyper@verizon.net> - 2012-03-02 14:08 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 12:38 -0700
Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-02 22:57 +0000
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 17:14 -0700
Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-03 02:25 +0000
Re: Mechanism to generate annotated "error codes" James Kuyper <jameskuyper@verizon.net> - 2012-03-03 06:10 -0500
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-03 16:12 -0500
Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-03 04:04 -0800
Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-03 15:05 +0000
Re: Mechanism to generate annotated "error codes" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-03 16:25 +0000
Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-03 16:26 -0500
Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-03 13:40 -0800
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-03 12:03 +1300
Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-02 15:45 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 17:18 -0700
Re: Mechanism to generate annotated "error codes" blp@cs.stanford.edu (Ben Pfaff) - 2012-03-02 15:08 -0800
Re: Mechanism to generate annotated "error codes" "BartC" <bc@freeuk.com> - 2012-03-03 10:30 +0000
Re: Mechanism to generate annotated "error codes" James Kuyper <jameskuyper@verizon.net> - 2012-03-03 06:19 -0500
Re: Mechanism to generate annotated "error codes" Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-03-03 15:15 +0200
Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-03 14:52 +0000
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 07:39 -0800
Re: Mechanism to generate annotated "error codes" Jonathan Leffler <jleffler@earthlink.net> - 2012-03-03 23:56 -0800
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 09:20 +1300
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-04 13:28 -0800
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 10:56 +1300
Re: Mechanism to generate annotated "error codes" "BartC" <bc@freeuk.com> - 2012-03-03 17:02 +0000
Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-03 12:30 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 19:15 -0700
Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-04 03:20 +0000
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 11:03 -0700
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 16:31 -0700
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 23:04 -0700
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-02 22:13 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 00:49 -0700
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 03:32 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 12:04 -0700
Re: Mechanism to generate annotated "error codes" Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-03 15:06 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 14:38 -0700
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 12:15 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 16:51 -0700
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-04 14:08 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 15:56 -0700
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 03:45 -0800
Re: Mechanism to generate annotated "error codes" Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-03 14:11 -0500
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 13:03 -0700
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 12:32 -0700
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 15:04 -0700
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-04 11:09 +1300
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 16:55 -0700
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-04 13:04 +1300
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 18:24 -0700
Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 14:30 -0800
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 17:06 -0700
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 10:09 +1300
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 16:03 -0700
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 13:26 +1300
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 22:21 -0700
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 20:46 +1300
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-05 10:54 -0700
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-06 10:02 +1300
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-05 16:09 -0700
Re: Mechanism to generate annotated "error codes" "BartC" <bc@freeuk.com> - 2012-03-06 10:54 +0000
Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-07 07:22 +1300
Re: Mechanism to generate annotated "error codes" gordonb.8sa24@burditt.org (Gordon Burditt) - 2012-03-06 08:51 -0600
Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-06 11:21 -0700
csiph-web