[2nd try via email]
,--------------- Forwarded message (begin)

 Subject: logic vs runtime errors
 From: Ross Boylan <ross@biostat.ucsf.edu>
 Date: Sat, 14 May 2005 14:08:59 -0700
 Newsgroup: comp.std.c++

 I find the discussion of logic vs runtime errors at the start of section
 19.1 of the standard confusing.

 "The distinguishing characteristic of logic errors is that they are due to
 errors in the internal logic of the program.  In theory, they are
 preventable"

 "By contrast, runtime errors are due to events beyond the scope of the
 program."

 Suppose someone enters an invalid input.  By these definitions, that
appears
 to be a runtime error.  But domain_error and invalid_arguments (for
 example) are subclasses of logic_error.

 I gather from the one previous thread I've found on this subject

(http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/357ccb7eea917a3c/be134ccc052ea3b1?q=logic+runtime+error+group:comp.std.c%2B%2B&rnum=1&hl=en#be134ccc052ea3b1),
 and some remarks by one of the committee members
 (http://www.freshsources.com/Except1/ALLISON.HTM), that bad inputs should
 be considered logic errors: "A logic error indicates an inconsistency in
 the internal logic of a program, or a violation of pre-conditions on the
 part of client software."  Elsewhere, someone said (basically) "your
 program could have checked for the problem, so it's a logic error."

 The remark about pre-conditions speaks directly to my concern, but it
simply
 is not in the standard.

 And the point "you could have checked" seems doubly unhelpful.  First, you
 could check for conditions leading to over and underflow too, but those are
 runtime_errors.  Second, the whole problem came up because I am checking,
 and I need to know what type of exception to raise if the check fails.

 So I guess it's clear enough what to do: use logic_errors for bad inputs.
 But I feel as if using logic_errors to report bad inputs contradicts the
 language of the standard.  Am I missing something?  Would a defect report
 be in order (there does not seem to be one on this topic)?

 The problem is that I read logic error as meaning a "this can't happen
here"
 type error, when something that you think your code has assured is not
 true.  Those clearly are logic errors.

 Running out of resources seems to be runtime error (but bad_alloc is not a
 subclass of runtime_error).

 It's the other stuff that's the problem.

`--------------- Forwarded message (end)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <E1DYopZ-0003hB-Ed@iron.libaux.ucsf.edu>,
 ross@biostat.ucsf.edu (Ross Boylan) wrote:

>  "The distinguishing characteristic of logic errors is that they are due to
>  errors in the internal logic of the program.  In theory, they are
>  preventable"
>
>  "By contrast, runtime errors are due to events beyond the scope of the
>  program."
>
>  Suppose someone enters an invalid input.  By these definitions, that
> appears
>  to be a runtime error.  But domain_error and invalid_arguments (for
>  example) are subclasses of logic_error.
>
>  I gather from the one previous thread I've found on this subject
>
> (http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/357ccb7
> eea917a3c/be134ccc052ea3b1?q=logic+runtime+error+group:comp.std.c%2B%2B&rnum=1
> &hl=en#be134ccc052ea3b1),
>  and some remarks by one of the committee members
>  (http://www.freshsources.com/Except1/ALLISON.HTM), that bad inputs should
>  be considered logic errors: "A logic error indicates an inconsistency in
>  the internal logic of a program, or a violation of pre-conditions on the
>  part of client software."  Elsewhere, someone said (basically) "your
>  program could have checked for the problem, so it's a logic error."
>
>  The remark about pre-conditions speaks directly to my concern, but it
> simply
>  is not in the standard.

It's implied.

>
>  And the point "you could have checked" seems doubly unhelpful.  First, you
>  could check for conditions leading to over and underflow too, but those are
>  runtime_errors.  Second, the whole problem came up because I am checking,
>  and I need to know what type of exception to raise if the check fails.

It's difficult to check whether a multiplication will overflow.  There's
nothing wrong with either input by itself, it's only a problem when you
combine them.  I suppose you could do:

 if (INT_MAX/a < b)
   { /* complain that a*b will overflow */ }

but I guess this is considered an overburdening requirement for most
programs.

On the other hand, if you're reading input, you're expected to check it
for proper syntax before passing it on to other functions, unless those
functions explicitly state that they're going to do the checks for you.

>  So I guess it's clear enough what to do: use logic_errors for bad inputs.
>  But I feel as if using logic_errors to report bad inputs contradicts the
>  language of the standard.  Am I missing something?  Would a defect report
>  be in order (there does not seem to be one on this topic)?
>
>  The problem is that I read logic error as meaning a "this can't happen
> here"
>  type error, when something that you think your code has assured is not
>  true.  Those clearly are logic errors.

I think it would be better to describe them as "this *shouldn't* happen
here", because the caller should have checked first.

Runtime errors are for things that the caller can't practically check
for.  A good example is running out of disk space when writing to a
file.  Even if you check for available space first (assuming you can
know ahead of time how much space you'll need), another process could be
writing files at the same time, so the space might not be available when
you finally need it.

Since you're trying to decide what types of errors to report in your
library, I guess you have to determine whether it's reasonable to expect
the caller to check for these situations before calling.  If so, it's a
logic error, otherwise it's a runtime error.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please don't overquote.


===================================== END OF MODERATOR'S COMMENT

Ross Boylan wrote:
> [2nd try via email]
> ,--------------- Forwarded message (begin)
>
>  Subject: logic vs runtime errors
>  From: Ross Boylan <ross@biostat.ucsf.edu>
>  Date: Sat, 14 May 2005 14:08:59 -0700
>  Newsgroup: comp.std.c++
>
>  I find the discussion of logic vs runtime errors at the start of
section
>  19.1 of the standard confusing.
>
>  "The distinguishing characteristic of logic errors is that they are
due to
>  errors in the internal logic of the program.  In theory, they are
>  preventable"
>
>  "By contrast, runtime errors are due to events beyond the scope of
the
>  program."
>
>  Suppose someone enters an invalid input.  By these definitions, that
> appears
>  to be a runtime error.  But domain_error and invalid_arguments (for
>  example) are subclasses of logic_error.

Actually, I'd say it's obviously a logic_error if the user
can enter a wrong input. The input control should enforce
valid input. i.e. a color picker should discard clicks
outside the windows, and any click inside is automatically
in [0,255].
Now, once the user input is validated, it should be acceptable to your
program logic. If it's still invalid,
your input control is wrong (or incorrectly initialized).

BTW, "incorrect" user input shouldn't lead to exceptions.
Bad input should be handled locally, and isn't exceptional.

HTH,
Michiel Salters

>  I gather from the one previous thread I've found on this subject
>
>
(http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/357ccb7eea917a3c/be134ccc052ea3b1?q=logic+runtime+error+group:comp.std.c%2B%2B&rnum=1&hl=en#be134ccc052ea3b1),
>  and some remarks by one of the committee members
>  (http://www.freshsources.com/Except1/ALLISON.HTM), that bad inputs
should
>  be considered logic errors: "A logic error indicates an
inconsistency in
>  the internal logic of a program, or a violation of pre-conditions on
the
>  part of client software."  Elsewhere, someone said (basically) "your
>  program could have checked for the problem, so it's a logic error."
>
>  The remark about pre-conditions speaks directly to my concern, but
it
> simply
>  is not in the standard.
>
>  And the point "you could have checked" seems doubly unhelpful.
First, you
>  could check for conditions leading to over and underflow too, but
those are
>  runtime_errors.  Second, the whole problem came up because I am
checking,
>  and I need to know what type of exception to raise if the check
fails.
>
>  So I guess it's clear enough what to do: use logic_errors for bad
inputs.
>  But I feel as if using logic_errors to report bad inputs contradicts
the
>  language of the standard.  Am I missing something?  Would a defect
report
>  be in order (there does not seem to be one on this topic)?
>
>  The problem is that I read logic error as meaning a "this can't
happen
> here"
>  type error, when something that you think your code has assured is
not
>  true.  Those clearly are logic errors.
>
>  Running out of resources seems to be runtime error (but bad_alloc is
not a
>  subclass of runtime_error).
>
>  It's the other stuff that's the problem.
>
> `--------------- Forwarded message (end)
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting
with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  ]
> [              --- Please see the FAQ before posting. ---
  ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html
  ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Friday 20 May 2005 03:00 pm, Barry Margolin wrote:

> In article <E1DYopZ-0003hB-Ed@iron.libaux.ucsf.edu>,
>  ross@biostat.ucsf.edu (Ross Boylan) wrote:
>
>>  "The distinguishing characteristic of logic errors is that they are due
>>  to
>>  errors in the internal logic of the program.  In theory, they are
>>  preventable"
>>
>>  "By contrast, runtime errors are due to events beyond the scope of the
>>  program."
>>
>>  Suppose someone enters an invalid input.  By these definitions, that
>> appears
>>  to be a runtime error.  But domain_error and invalid_arguments (for
>>  example) are subclasses of logic_error.
>>
[...]
[One site advises] that bad inputs
>>  should be considered logic errors: "A logic error indicates an
>>  inconsistency in the internal logic of a program, or a violation of
>>  pre-conditions on the
>>  part of client software."  Elsewhere, someone said (basically) "your
>>  program could have checked for the problem, so it's a logic error."
>>
>>  The remark about pre-conditions speaks directly to my concern, but it
>>  simply is not in the standard.
>
> It's implied.

My reading is the opposite: user events, as stuff "beyond the scope of the
program" are associated with runtime errors.  Precondition violations only
indicates a logic error if the cause is some internal failure in my
program.

Also, every function has as a precondition "sufficient resources" (disk,
memory), but failure there appears to be considered a runtime error.

>>  And the point "you could have checked" seems doubly unhelpful.  First,
[snip]

> It's difficult to check whether a multiplication will overflow.
[...]
> On the other hand, if you're reading input, you're expected to check it
> for proper syntax before passing it on to other functions, unless those
> functions explicitly state that they're going to do the checks for you.

First of all, the logic vs runtime errors splits the world in two.  A
two-way split can not possibly accommodate 2 distinctions, such as internal
vs external and easy vs hard to check, unless those always come down to the
same thing.  I don't think they do.

Second, you and Michiel Salters assume that bad input is easy to check.
That is not always so, and in particular it is not the case for my
situation.  The user specifies a relatively complex model
which may turn out to be inconsistent with the observed input data.  It is
not possible to know whether that's the case until all model generated
paths are created.

Salters also wrote:
> BTW, "incorrect" user input shouldn't lead to exceptions.
> Bad input should be handled locally, and isn't exceptional.
The problem with the inputs, if there is one, gets discovered fairly deep
into processing.  I'm not quite sure what you mean by "handled locally",
but the most convenient way to deal with this issue is to raise an
exception.  This is caught by a higher level and reported to the caller.
My code is basically a subroutine, and does not control the user interface.

Given that the "user" is a calling program, I see no reason to avoid error
report by exceptions.  I am not saying the program crashes and burns as a
result of the exception being thrown.  In fact, the caller simply receives
a return value that indicates an error, and the nature of the error (the
user is a C, not C++, program).

[...]
> Runtime errors are for things that the caller can't practically check
> for.
Again, in my case the caller can't check for the error without duplicating
most of the logic of my program.
> A good example is running out of disk space when writing to a
> file.  Even if you check for available space first (assuming you can
> know ahead of time how much space you'll need), another process could be
> writing files at the same time, so the space might not be available when
> you finally need it.
>
I'd call that a situation where the caller couldn't even theoretically check
for the problem.

> Since you're trying to decide what types of errors to report in your
> library, I guess you have to determine whether it's reasonable to expect
> the caller to check for these situations before calling.  If so, it's a
> logic error, otherwise it's a runtime error.
>
OK, so are you saying I should be using runtime errors for my situation?
But that advice seems to be based on the "practical to check" standard,
which appears to differ from what the C++ standard is trying to get at.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6lqe3$2b60@itssrv1.ucsf.edu>,
 ross@biostat.ucsf.edu (Ross Boylan) wrote:

> Again, in my case the caller can't check for the error without duplicating
> most of the logic of my program.

That sounds similar to the example I gave of trying to prevent
overflows.  To prevent a multiplication from overflowing, you have to
duplicate most of the logic of multiplication.

Since the situations are similar, I suggest you adopt a similar tactic
regarding the exceptions that are raised.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]