C++ error handling -> error is rare -> throw and forget

[wij]

I just skimmed the "Error handling" section of https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
It is really blink-talk, all the time till now. It read to me (just one point):
Because error is rare, so throw it (and forget) is justified.
I say practical codes have to written for all possible branches, rare or not
is not an issue. Take a basic example of reading an integer from the standard
input for instance:

int num;
std::cin >> num;

Of course, this piece is mostly for demo. But what if we want practical codes
to read an integer from the standard input? I think the answer is 'no way' for
application developers. stdc++ library developers keep playing blind and cheat.
One possible reason, stdc++ is for checking and demo. the feature of C++
itself, not really for application developer.

[Öö Tiib]

On Friday, 7 July 2023 at 17:23:36 UTC+3, wij wrote:
> I just skimmed the "Error handling" section of https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
> It is really blink-talk, all the time till now. It read to me (just one point):
> Because error is rare, so throw it (and forget) is justified.
> I say practical codes have to written for all possible branches, rare or not
> is not an issue. Take a basic example of reading an integer from the standard
> input for instance:
>
> int num;
> std::cin >> num;
>
> Of course, this piece is mostly for demo.
>

It is unclear what you mean by that example. Yes, majority of software
does not communicate reading text from standard input using C++ streams.

> But what if we want practical codes
> to read an integer from the standard input? I think the answer is 'no way' for
> application developers.
>

Why you think so? The C++ streams can be and are useful. Just not always.

> stdc++ library developers keep playing blind and cheat.
> One possible reason, stdc++ is for checking and demo. the feature of C++
> itself, not really for application developer.
>

You mean GNU C++ library implementers? On the contrary ... most contributors
are rather good and well paid C++ developers. They manage to implement
what standard requires and quite well IMHO.

[wij]

On Saturday, July 8, 2023 at 12:37:24 AM UTC+8, Öö Tiib wrote:
> On Friday, 7 July 2023 at 17:23:36 UTC+3, wij wrote:
> > I just skimmed the "Error handling" section of https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
> > It is really blink-talk, all the time till now. It read to me (just one point):
> > Because error is rare, so throw it (and forget) is justified.
> > I say practical codes have to written for all possible branches, rare or not
> > is not an issue. Take a basic example of reading an integer from the standard
> > input for instance:
> >
> > int num;
> > std::cin >> num;
> >
> > Of course, this piece is mostly for demo.
> >
> It is unclear what you mean by that example. Yes, majority of software
> does not communicate reading text from standard input using C++ streams.

Yes, not majority, but not few programs communicate through fd=0,1,2.

> > But what if we want practical codes
> > to read an integer from the standard input? I think the answer is 'no way' for
> > application developers.
> >
> Why you think so? The C++ streams can be and are useful. Just not always.

I might understand what you mean. As I know, C++ stream I/O is compatible with
C stream I/O. Many system commands rely on it. Applications use it for
convention reasons but not limited. Not fit, don't use it.

> > stdc++ library developers keep playing blind and cheat.
> > One possible reason, stdc++ is for checking and demo. the feature of C++
> > itself, not really for application developer.
> >
> You mean GNU C++ library implementers? On the contrary ... most contributors
> are rather good and well paid C++ developers. They manage to implement
> what standard requires and quite well IMHO.

Let say "E.3: Use exceptions for error handling only", a section in the link above.
The statement is stronger than before. But, what do general people read, while
the real meaning keeps changing? (I mis-read the file CppCoreGuidelines and
example program) ...So, in the end, I think the meaning of 'error' depends.
IMO, error reports (of a function) are just info. for caller to branch execution
path. Throwing (setjmp/longjmp) error, in general, will lose the error context.
Application will have less confident what is really caught to choose preciser action.
The result is larger portion of the program is 'reset'.
(By the way, I think error report by errno might not be bad, also practical)

[wij]

I just recall that in the early days, I had posted a similar post like below, the reply
was "that's user's error handling strategy problem". Maybe this is already known
, I don't known what the pro-throw-error people thought.

Losing context: The error thrown may not associate to the function being called.

int read_integer(size_t maxlen) {
int v;
if(maxlen>10) {
throw Invalid_Argument;
}
// read string and convert to integer (Invalid_Argument may be thrown)
return v;
}

void f(int count) {
int v;
if(count<0) {
throw Invalid_Argument;
}
for(int i=0; i<count; ++i) {
try {
v= read_integer(8);
}
catch (Invalid_Argument) {
// May not be the Invalid_Argument that read_integer(..) threw.
// All decisions based on this assumption will be wrong.
}
cout << v;
}
}

The Invalid_Argument caught in f may not be responsible by the read_integer(8).
Likewise, if Invalid_Argument is rethrown, it does not indicate the count
argument of f is invalid.

[Öö Tiib]

The example was where exception was used for something other than for
error handling. And it was said that you should not.

> > IMO, error reports (of a function) are just info. for caller to branch execution
> > path. Throwing (setjmp/longjmp) error, in general, will lose the error context.
> > Application will have less confident what is really caught to choose preciser action.
> > The result is larger portion of the program is 'reset'.
> > (By the way, I think error report by errno might not be bad, also practical)
> I just recall that in the early days, I had posted a similar post like below, the reply
> was "that's user's error handling strategy problem". Maybe this is already known
> , I don't known what the pro-throw-error people thought.
>
> Losing context: The error thrown may not associate to the function being called.
>

That is irrelevant about rule that you should not use exceptions for something that
is not error handling.

Yes programmer can "throw false;" on every error and then complain that all
information that is needed for handling was lost.
Question: Whose fault it was: (a) exceptions or (b) programmer? Why?

[Paavo Helde]

07.07.2023 23:32 wij kirjutas:
> Let say "E.3: Use exceptions for error handling only", a section in the link above.
> The statement is stronger than before. But, what do general people read, while
> the real meaning keeps changing? (I mis-read the file CppCoreGuidelines and
> example program) ...So, in the end, I think the meaning of 'error' depends.

Exceptions should be used for exceptional circumstances. These might or
might not be errors. Imagine a function which checks the presence of a
file on a disk. Sometimes the absence of file might be an error and/or
exceptional, sometimes its presence might be an error and/or
exceptional. So this function cannot throw an exception by itself, it
should just return a status or error code. It would be the task of the
caller to decide in which case to throw exceptions.

> IMO, error reports (of a function) are just info. for caller to branch execution
> path. Throwing (setjmp/longjmp) error, in general, will lose the error context.

Not necessarily. The upper frames can catch the exception, add context
details to the exception, and rethrow it. A major benefit of C++
exceptions over longjmp (apart of not ruining RAII of course) is a way
to package extra information in the thrown exception object.

> Application will have less confident what is really caught to choose preciser action.
> The result is larger portion of the program is 'reset'.
> (By the way, I think error report by errno might not be bad, also practical)

It often makes sense to have a low-level function which returns an error
code, and a couple of higher level function which check that error code
and throw an exception when appropriate. Most code would use the higher
level functions, but these higher level functions would be built on the
low-level function, like in the example above.

[wij]

Sounds like a word game.
You mean the "int read_integer(size_t)" case shown is not error handling?

> Yes programmer can "throw false;" on every error and then complain that all
> information that is needed for handling was lost.
> Question: Whose fault it was: (a) exceptions or (b) programmer? Why?

If you are referring to the E.3 case, I am speechless.
---------

E.3: Use exceptions for error handling only

Reason

To keep error handling separated from “ordinary code.” C++ implementations tend to be optimized based on the assumption that exceptions are rare. Example, don’t

// don't: exception not used for error handling
int find_index(vector<string>& vec, const string& x)
{
try {
for (gsl::index i = 0; i < vec.size(); ++i)
if (vec[i] == x) throw i; // found x
}
catch (int i) {
return i;
}
return -1; // not found
}
---------

What kind of programmer will write such codes? And, as said, CONTEXT LOSS.
All (nearly) kind of such coding is not doing what the author thought. And I
believe this is the idea what the stdc++ conveys. Please, show us a general
enough usecase of 'exception' for general C++ programmers.

(I ignored your all-possible question)

[wij]

All look like rephrasing the copy of blind-talk from stdc++.
Simple reply: Throwing error cannot replace returning error,
returning error can replace throwing error.

[Öö Tiib]

I mean your example of bad error handling using exceptions is irrelevant to rule
that exceptions should not be used for something else but for error handling.

> > Yes programmer can "throw false;" on every error and then complain that all
> > information that is needed for handling was lost.
> > Question: Whose fault it was: (a) exceptions or (b) programmer? Why?
> If you are referring to the E.3 case, I am speechless.
>

I am asking question about your irrelevant to E.3 claims of exceptions losing
vital for error handling information. Why you are speechless?

> E.3: Use exceptions for error handling only

...

>
> What kind of programmer will write such codes? And, as said, CONTEXT LOSS.
> All (nearly) kind of such coding is not doing what the author thought.
>

It was example of *what* *not* *to* *do*. It was using exception for not handling
error, but doing something else.

> And I
> believe this is the idea what the stdc++ conveys. Please, show us a general
> enough usecase of 'exception' for general C++ programmers.
>

But why to "believe"? Programming is not about faith and religion. Read source
code, read on from E.3, there are more examples what to do and what not to do.

> (I ignored your all-possible question)
>

Why? It was simple. OK, another question: How can throwing exception from
constructor be replaced by returning exception?

[Paavo Helde]

08.07.2023 15:11 wij kirjutas:

> All look like rephrasing the copy of blind-talk from stdc++.
> Simple reply: Throwing error cannot replace returning error,
> returning error can replace throwing error.

Of course. The Turing machine does not have exceptions and can cope
fine. Meaning that if you don't like exceptions, you don't have to use them.

In other news, "goto" can replace both "while" and "for". But "can" does
not imply "must" nor even "should".

[wij]

'return' in ctor is invalid.
I was responding to Paavo Helde to say that 'return T' and 'throw T' are
different, the latter one lose context. It seems both you still don't get it.

[wij]

You don't know what you are talking about.

[Öö Tiib]

So it can't be.

> I was responding to Paavo Helde to say that 'return T' and 'throw T' are
> different, the latter one lose context. It seems both you still don't get it.

We get it, you are simply incorrect. Only programmer can lose information
about cause of error by not returning nor throwing that information.
Nonsense can be expressed in every useful language in endless ways
but if it is done then it is not problem of language but user of it.

[V]

Tore näha ka eesti rahvast newsgroupides tänapäeval..

[Paavo Helde]

08.07.2023 22:00 V kirjutas:
> Tore näha ka eesti rahvast newsgroupides tänapäeval..

Loen muuseas hetkel ka Maniakkide Tänava ulmekat, kus kosmoselaeva
kapten on eestlane ja soomlased-rootslased on muud vähemtähtsamad tegelased.

[Man]

Kuhu Sul ikka minna siit armsalt planeedilt nimega Maa ?

Mina küll siit minema ei taha minna.

[wij]

Snippet from https://www.geeksforgeeks.org/exception-handling-c/

#include <iostream>
using namespace std;

// Here we specify the exceptions that this function
// throws.
void fun(int *ptr, int x) throw (int *, int) // Dynamic Exception specification
{
if (ptr == NULL)
throw ptr;
if (x == 0)
throw x;
/* Some functionality */
}

int main()
{
try {
fun(NULL, 0);
}
catch(...) {
cout << "Caught exception from fun()";
}
return 0;
}

Note : The use of Dynamic Exception Specification has been deprecated since C++11. One of the reasons for it may be that it can randomly abort your program. This can happen when you throw an exception of another type which is not mentioned in the dynamic exception specification. Your program will abort itself because in that scenario, it calls (indirectly) terminate(), which by default calls abort().
------------

"Caught exception from fun()" is not guaranteed (an illusion).
Even throw specification would survive, the context loss problem is still unsolved.

"Throw (std?)'exception' and let the caller knows how to deal with it deals with it"
... How convenient the "Advanced error handling mechanism" is! LIE, or like olcott,
he did not know he kept lying all these years.

[wij]

In all, I hope that stdc++ makes such usecase of "Advanced error handling mechanism" clear:

int main()
{
try {
fun(0);
}
catch(Exception e) {
// Don't assume the e has anything specific to fun(0)
// fun(0) is not responsible to what is thrown.
}
return 0;
}