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-02 00:30 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <jipsv0$rkd$1@speranza.aioe.org> (permalink) |
| References | <jiojq3$3cm$1@speranza.aioe.org> <error-codes-20120302005428-Supersedes@ram.dialup.fu-berlin.de> |
Hi Stefan,
On 3/1/2012 5:00 PM, Stefan Ram wrote:
> Supersedes:<error-codes-20120302005428@ram.dialup.fu-berlin.de>
> [removed "list0.c" with Supersedes]
>
> Don Y<this@isnotme.com> writes:
>> Managing these "enumerations" gets to be tedious and error
>> prone. Which *values* have been assigned?
>
> That's easy. Just keep a single table with two rows:
> number and meaning. There, you can always find the
> answer to this question. (You can use the include
> file with the define-directives.)
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)
There is nothing that ensures:
#define TOO_MANY_DIGITS (375)
is actually *used* anywhere! Does its absence mean that some
test has been forgotten in the code? Or, that the test has
been made unnecessary (and, thus, the error code associated
with it) due to a change in the implementation?
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!)
And, if you have multiple such tables, you have to ensure the
"number spaces" for each do not overlap.
I.e., it forces all of the housekeeping onto the developer.
>> What is a good value to pick for this new 'condition'?
>
> The next consecutive number, like: 1, 2, 3, ...
This implies you have *all* of the numbers in one place.
And, that none of the subsystems/libraries are ever enhanced.
("Gee, I need to verify the value entered doesn't overflow
a double. Let me create a new error code DOUBLE_OVERFLOW
and I'll just assign it the value after MOTOR_OVERHEATED...")
How do you find which errors are thrown by each module/library/etc.?
How do you ensure you don't already have "OVERFLOW_DOUBLE" hidden
away in that SINGLE long list of error codes?
>> etc.
>
> Feel free to ask more questions!
>
>> The problem then becomes one of making that information available
>> to other *consumers*! I.e., wrapping it in a header file that
>> others can reference.
>
> Where's the problem? You create a header file and put
> the definitions in it:
>
> #define ERROR_NO_MORE_MEMORY_AVAILABLE 1
> #define ERROR_CANT_OPEN_AT_LEAST_ONE_FILE_FOR_READ_ACCESS 2
> ...
> #define ERROR_AT_LEAST_ONE_CLIENT_SUPPLIED_NUMERIC_VALIDITY_CONDITION_IS_NOT_FULFILLED 2351
See above.
>> A "solution" also needs to address the problem of *explaining*
>> the "result" (to the ultimate user).
>
> That's a separate problem of the application author.
No! That's what leads to "bad value" type error messages!
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.
A given layer in an application should only be concerned with
explaining the issues that *it* enforces. 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.
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?
>> very narrowly defined context: i.e., you can tell the user
>> "Multiple decimal points encountered" -- though you can't
>> indicate the role that the value being entered plays in the
>> application (is this a person's wages? the weight of a
>> newborn child? the average lifespan of a male tortoise?).
>
> This is known to the author of the application.
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 currently do this with a mix of ad hoc measures.
>
> I use numeric values with meanings relative to a function
> and transform them when passing them upward to the next
> caller.
>
> For example,
>
> int filemove( LPTSTR const target, LPTSTR const source )
> { BOOL const success = MoveFile( source, target );
> int const terminate = success ? 1 : filecall_error();
> return terminate; }
>
> »MoveFile« returns »success« to describe its success,
> the semantics of which are being described in the
> »MoveFile« documentation.
>
> »filemove« uses an int value with semantics being
> described in the »filemove« documentation. This int
> value is being determined based on the result of two
> other functions called in »filemove«: »MoveFile«
> and »filecall_error«.
And how does the person *using* the application that encapsulates
this code know what's gone wrong with his *use* of the application?
> There are no global semantics for result codes in
> this case.
filemove exposes the error from MoveFile to upper levels.
I.e., the error codes returned by MoveFile() *include*
(and, thus, have the potential to conflict with) those
of filemove()).
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? 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.
(Does main() have code in it to explain errors that are essentially
percolated upwards from filemove() -- regardless of how *deep* in
the application the error was detected?)
> For a slightly larger example, see list1.c in
>
> http://www.purl.org/stefan_ram/pub/listenverarbeitung_in_c
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