Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Disk crisis, please clean up!


devel / comp.lang.c++ / Re: C++ error handling -> error is rare -> throw and forget

SubjectAuthor
* C++ error handling -> error is rare -> throw and forgetwij
`* Re: C++ error handling -> error is rare -> throw and forgetÖö Tiib
 `* Re: C++ error handling -> error is rare -> throw and forgetwij
  +* Re: C++ error handling -> error is rare -> throw and forgetwij
  |`* Re: C++ error handling -> error is rare -> throw and forgetÖö Tiib
  | `* Re: C++ error handling -> error is rare -> throw and forgetwij
  |  `* Re: C++ error handling -> error is rare -> throw and forgetÖö Tiib
  |   `* Re: C++ error handling -> error is rare -> throw and forgetwij
  |    `* Re: C++ error handling -> error is rare -> throw and forgetÖö Tiib
  |     +* Re: C++ error handling -> error is rare -> throw and forgetV
  |     |`* [OT] [OT] [OT] Re: C++ error handling -> error is rare -> throw andPaavo Helde
  |     | `- Re: [OT] [OT] [OT] Re: C++ error handling -> error is rare -> throwMan
  |     `* Re: C++ error handling -> error is rare -> throw and forgetwij
  |      `- Re: C++ error handling -> error is rare -> throw and forgetwij
  `* Re: C++ error handling -> error is rare -> throw and forgetPaavo Helde
   `* Re: C++ error handling -> error is rare -> throw and forgetwij
    `* Re: C++ error handling -> error is rare -> throw and forgetPaavo Helde
     `- Re: C++ error handling -> error is rare -> throw and forgetwij

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

<bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=684&group=comp.lang.c%2B%2B#684

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:4688:b0:762:1b2f:ec53 with SMTP id bq8-20020a05620a468800b007621b2fec53mr21121qkb.7.1688739803551;
Fri, 07 Jul 2023 07:23:23 -0700 (PDT)
X-Received: by 2002:a17:90a:f68c:b0:263:49c1:4325 with SMTP id
cl12-20020a17090af68c00b0026349c14325mr2340961pjb.3.1688739803179; Fri, 07
Jul 2023 07:23:23 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Fri, 7 Jul 2023 07:23:22 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
Subject: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Fri, 07 Jul 2023 14:23:23 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1822
 by: wij - Fri, 7 Jul 2023 14:23 UTC

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.

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

<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=690&group=comp.lang.c%2B%2B#690

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:190:b0:403:3bc1:54e9 with SMTP id s16-20020a05622a019000b004033bc154e9mr16359qtw.12.1688747835317;
Fri, 07 Jul 2023 09:37:15 -0700 (PDT)
X-Received: by 2002:a17:902:ba8c:b0:1ae:6895:cb96 with SMTP id
k12-20020a170902ba8c00b001ae6895cb96mr4677017pls.5.1688747833612; Fri, 07 Jul
2023 09:37:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Fri, 7 Jul 2023 09:37:12 -0700 (PDT)
In-Reply-To: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=145.14.19.203; posting-account=pysjKgkAAACLegAdYDFznkqjgx_7vlUK
NNTP-Posting-Host: 145.14.19.203
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: oot...@hot.ee (Öö Tiib)
Injection-Date: Fri, 07 Jul 2023 16:37:15 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2511
 by: Öö Tiib - Fri, 7 Jul 2023 16:37 UTC

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.

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

<0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=708&group=comp.lang.c%2B%2B#708

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ac8:5b44:0:b0:400:9779:c7c0 with SMTP id n4-20020ac85b44000000b004009779c7c0mr17122qtw.9.1688761931179;
Fri, 07 Jul 2023 13:32:11 -0700 (PDT)
X-Received: by 2002:a17:902:ec88:b0:1b5:2b14:5f2c with SMTP id
x8-20020a170902ec8800b001b52b145f2cmr6202658plg.4.1688761930422; Fri, 07 Jul
2023 13:32:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Fri, 7 Jul 2023 13:32:09 -0700 (PDT)
In-Reply-To: <0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com> <0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Fri, 07 Jul 2023 20:32:11 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: wij - Fri, 7 Jul 2023 20:32 UTC

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)

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

<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=709&group=comp.lang.c%2B%2B#709

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:191b:b0:767:3135:5710 with SMTP id bj27-20020a05620a191b00b0076731355710mr16880qkb.8.1688777854002;
Fri, 07 Jul 2023 17:57:34 -0700 (PDT)
X-Received: by 2002:a17:902:a502:b0:1b5:2c0b:fa72 with SMTP id
s2-20020a170902a50200b001b52c0bfa72mr5826543plq.12.1688777853305; Fri, 07 Jul
2023 17:57:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Fri, 7 Jul 2023 17:57:32 -0700 (PDT)
In-Reply-To: <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Sat, 08 Jul 2023 00:57:33 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 5128
 by: wij - Sat, 8 Jul 2023 00:57 UTC

On Saturday, July 8, 2023 at 4:32:20 AM UTC+8, wij wrote:
> 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)

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.

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

<15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=711&group=comp.lang.c%2B%2B#711

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ad4:4f24:0:b0:635:d9b4:ba20 with SMTP id fc4-20020ad44f24000000b00635d9b4ba20mr16786qvb.11.1688785579986;
Fri, 07 Jul 2023 20:06:19 -0700 (PDT)
X-Received: by 2002:a05:6a00:1409:b0:67a:fe8f:83f8 with SMTP id
l9-20020a056a00140900b0067afe8f83f8mr9775542pfu.5.1688785579239; Fri, 07 Jul
2023 20:06:19 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Fri, 7 Jul 2023 20:06:18 -0700 (PDT)
In-Reply-To: <cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=145.14.19.203; posting-account=pysjKgkAAACLegAdYDFznkqjgx_7vlUK
NNTP-Posting-Host: 145.14.19.203
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: oot...@hot.ee (Öö Tiib)
Injection-Date: Sat, 08 Jul 2023 03:06:19 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 5129
 by: Öö Tiib - Sat, 8 Jul 2023 03:06 UTC

On Saturday, 8 July 2023 at 03:57:43 UTC+3, wij wrote:
> On Saturday, July 8, 2023 at 4:32:20 AM UTC+8, wij wrote:
> > 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.
>
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?

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

<u8b8ik$1mpau$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=712&group=comp.lang.c%2B%2B#712

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: eesn...@osa.pri.ee (Paavo Helde)
Newsgroups: comp.lang.c++
Subject: Re: C++ error handling -> error is rare -> throw and forget
Date: Sat, 8 Jul 2023 12:00:03 +0300
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <u8b8ik$1mpau$1@dont-email.me>
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com>
<0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 8 Jul 2023 09:00:04 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b1abbb8f30f353fabe8e09b6e1f85c80";
logging-data="1795422"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19K45ZmOKdaG0eX37rPmBNS7rj3A5XNIq0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.12.0
Cancel-Lock: sha1:qN/7zxeefKvNrcZ8o3TddbH0SR4=
In-Reply-To: <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
Content-Language: en-US
 by: Paavo Helde - Sat, 8 Jul 2023 09:00 UTC

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.

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

<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=713&group=comp.lang.c%2B%2B#713

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ad4:5985:0:b0:635:93ec:4d8a with SMTP id ek5-20020ad45985000000b0063593ec4d8amr20439qvb.10.1688818146097;
Sat, 08 Jul 2023 05:09:06 -0700 (PDT)
X-Received: by 2002:a17:902:9f96:b0:1b8:9866:db2a with SMTP id
g22-20020a1709029f9600b001b89866db2amr7204625plq.10.1688818145463; Sat, 08
Jul 2023 05:09:05 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 05:09:04 -0700 (PDT)
In-Reply-To: <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Sat, 08 Jul 2023 12:09:06 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: wij - Sat, 8 Jul 2023 12:09 UTC

On Saturday, July 8, 2023 at 11:06:28 AM UTC+8, Öö Tiib wrote:
> On Saturday, 8 July 2023 at 03:57:43 UTC+3, wij wrote:
> > On Saturday, July 8, 2023 at 4:32:20 AM UTC+8, wij wrote:
> > > 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.
> >
> 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.

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)

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

<2a8dc6e2-0500-4401-8230-425858b3a665n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=714&group=comp.lang.c%2B%2B#714

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:24ce:b0:767:36d8:b67d with SMTP id m14-20020a05620a24ce00b0076736d8b67dmr19073qkn.4.1688818317681;
Sat, 08 Jul 2023 05:11:57 -0700 (PDT)
X-Received: by 2002:ac8:7c4d:0:b0:403:996b:3ae with SMTP id
o13-20020ac87c4d000000b00403996b03aemr12986qtv.9.1688818317424; Sat, 08 Jul
2023 05:11:57 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 05:11:57 -0700 (PDT)
In-Reply-To: <u8b8ik$1mpau$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<u8b8ik$1mpau$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2a8dc6e2-0500-4401-8230-425858b3a665n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Sat, 08 Jul 2023 12:11:57 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3538
 by: wij - Sat, 8 Jul 2023 12:11 UTC

On Saturday, July 8, 2023 at 5:00:25 PM UTC+8, Paavo Helde wrote:
> 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.

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.

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

<d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=718&group=comp.lang.c%2B%2B#718

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ad4:4f0b:0:b0:634:beaa:5a99 with SMTP id fb11-20020ad44f0b000000b00634beaa5a99mr25947qvb.3.1688830058292;
Sat, 08 Jul 2023 08:27:38 -0700 (PDT)
X-Received: by 2002:a65:6a84:0:b0:55b:49a8:49bd with SMTP id
q4-20020a656a84000000b0055b49a849bdmr5900313pgu.2.1688830057789; Sat, 08 Jul
2023 08:27:37 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 08:27:37 -0700 (PDT)
In-Reply-To: <536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=145.14.19.203; posting-account=pysjKgkAAACLegAdYDFznkqjgx_7vlUK
NNTP-Posting-Host: 145.14.19.203
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: oot...@hot.ee (Öö Tiib)
Injection-Date: Sat, 08 Jul 2023 15:27:38 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6988
 by: Öö Tiib - Sat, 8 Jul 2023 15:27 UTC

On Saturday, 8 July 2023 at 15:09:16 UTC+3, wij wrote:
> On Saturday, July 8, 2023 at 11:06:28 AM UTC+8, Öö Tiib wrote:
> > On Saturday, 8 July 2023 at 03:57:43 UTC+3, wij wrote:
> > > On Saturday, July 8, 2023 at 4:32:20 AM UTC+8, wij wrote:
> > > > 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.
> > >
> > 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.
> Sounds like a word game.
> You mean the "int read_integer(size_t)" case shown is not error handling?

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?

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

<u8c28p$1pomo$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=720&group=comp.lang.c%2B%2B#720

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: eesn...@osa.pri.ee (Paavo Helde)
Newsgroups: comp.lang.c++
Subject: Re: C++ error handling -> error is rare -> throw and forget
Date: Sat, 8 Jul 2023 19:18:32 +0300
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <u8c28p$1pomo$1@dont-email.me>
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com>
<0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<u8b8ik$1mpau$1@dont-email.me>
<2a8dc6e2-0500-4401-8230-425858b3a665n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 8 Jul 2023 16:18:33 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b1abbb8f30f353fabe8e09b6e1f85c80";
logging-data="1893080"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//uAX4v3mHR2wt2wZRjH/JDwe/JL50zfw="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.12.0
Cancel-Lock: sha1:NClcuF4SE0+I8lKOCiHAzElZNBg=
In-Reply-To: <2a8dc6e2-0500-4401-8230-425858b3a665n@googlegroups.com>
Content-Language: en-US
 by: Paavo Helde - Sat, 8 Jul 2023 16:18 UTC

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".

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

<648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=721&group=comp.lang.c%2B%2B#721

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ad4:4ba7:0:b0:635:90f3:3a05 with SMTP id i7-20020ad44ba7000000b0063590f33a05mr25279qvw.0.1688839487830;
Sat, 08 Jul 2023 11:04:47 -0700 (PDT)
X-Received: by 2002:a63:7f51:0:b0:55a:db19:1724 with SMTP id
p17-20020a637f51000000b0055adb191724mr6087637pgn.8.1688839487236; Sat, 08 Jul
2023 11:04:47 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 11:04:46 -0700 (PDT)
In-Reply-To: <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com> <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Sat, 08 Jul 2023 18:04:47 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 136
 by: wij - Sat, 8 Jul 2023 18:04 UTC

On Saturday, July 8, 2023 at 11:27:47 PM UTC+8, Öö Tiib wrote:
> On Saturday, 8 July 2023 at 15:09:16 UTC+3, wij wrote:
> > On Saturday, July 8, 2023 at 11:06:28 AM UTC+8, Öö Tiib wrote:
> > > On Saturday, 8 July 2023 at 03:57:43 UTC+3, wij wrote:
> > > > On Saturday, July 8, 2023 at 4:32:20 AM UTC+8, wij wrote:
> > > > > 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.
> > > >
> > > 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.
> > Sounds like a word game.
> > You mean the "int read_integer(size_t)" case shown is not error handling?
> 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?

'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.

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

<8a431eea-7633-479f-a779-f9cbdf20db81n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=722&group=comp.lang.c%2B%2B#722

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:6214:140c:b0:635:e314:b098 with SMTP id pr12-20020a056214140c00b00635e314b098mr23496qvb.3.1688839529329;
Sat, 08 Jul 2023 11:05:29 -0700 (PDT)
X-Received: by 2002:a63:344a:0:b0:55b:33b8:609f with SMTP id
b71-20020a63344a000000b0055b33b8609fmr5757559pga.11.1688839528755; Sat, 08
Jul 2023 11:05:28 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 11:05:28 -0700 (PDT)
In-Reply-To: <u8c28p$1pomo$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<u8b8ik$1mpau$1@dont-email.me> <2a8dc6e2-0500-4401-8230-425858b3a665n@googlegroups.com>
<u8c28p$1pomo$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8a431eea-7633-479f-a779-f9cbdf20db81n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Sat, 08 Jul 2023 18:05:29 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2030
 by: wij - Sat, 8 Jul 2023 18:05 UTC

On Sunday, July 9, 2023 at 12:18:51 AM UTC+8, Paavo Helde wrote:
> 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".

You don't know what you are talking about.

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

<ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=726&group=comp.lang.c%2B%2B#726

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:6214:4c1d:b0:635:9ddf:fd9c with SMTP id qh29-20020a0562144c1d00b006359ddffd9cmr47529qvb.5.1688842203138;
Sat, 08 Jul 2023 11:50:03 -0700 (PDT)
X-Received: by 2002:a63:8bca:0:b0:542:c9ed:b with SMTP id j193-20020a638bca000000b00542c9ed000bmr5970135pge.7.1688842202588;
Sat, 08 Jul 2023 11:50:02 -0700 (PDT)
Path: i2pn2.org!rocksolid2!news.neodome.net!news.ortolo.eu!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 11:50:02 -0700 (PDT)
In-Reply-To: <648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=145.14.19.203; posting-account=pysjKgkAAACLegAdYDFznkqjgx_7vlUK
NNTP-Posting-Host: 145.14.19.203
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com> <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
<648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: oot...@hot.ee (Öö Tiib)
Injection-Date: Sat, 08 Jul 2023 18:50:03 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Öö Tiib - Sat, 8 Jul 2023 18:50 UTC

On Saturday, 8 July 2023 at 21:04:57 UTC+3, wij wrote:
> On Saturday, July 8, 2023 at 11:27:47 PM UTC+8, Öö Tiib wrote:
> > On Saturday, 8 July 2023 at 15:09:16 UTC+3, wij wrote:
> > > On Saturday, July 8, 2023 at 11:06:28 AM UTC+8, Öö Tiib wrote:
> > > > On Saturday, 8 July 2023 at 03:57:43 UTC+3, wij wrote:
> > > > > On Saturday, July 8, 2023 at 4:32:20 AM UTC+8, wij wrote:
> > > > > > 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.
> > > > >
> > > > 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.
> > > Sounds like a word game.
> > > You mean the "int read_integer(size_t)" case shown is not error handling?
> > 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?
>
> 'return' in ctor is invalid.
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.

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

<2cbd90d2-d146-4de0-b1d8-4a10b0be697bn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=727&group=comp.lang.c%2B%2B#727

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:180b:b0:403:9734:9485 with SMTP id t11-20020a05622a180b00b0040397349485mr42529qtc.1.1688842840466;
Sat, 08 Jul 2023 12:00:40 -0700 (PDT)
X-Received: by 2002:a63:705e:0:b0:54f:d553:fbe6 with SMTP id
a30-20020a63705e000000b0054fd553fbe6mr6292086pgn.2.1688842840154; Sat, 08 Jul
2023 12:00:40 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 12:00:39 -0700 (PDT)
In-Reply-To: <ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=85.253.185.93; posting-account=ykVvQgoAAACp4VEbaWPL3R35slQMB5Au
NNTP-Posting-Host: 85.253.185.93
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com> <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
<648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com> <ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2cbd90d2-d146-4de0-b1d8-4a10b0be697bn@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: vvvvvvvv...@hotmail.com (V)
Injection-Date: Sat, 08 Jul 2023 19:00:40 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: V - Sat, 8 Jul 2023 19:00 UTC

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

On Saturday, July 8, 2023 at 9:50:13 PM UTC+3, Öö Tiib wrote:
> On Saturday, 8 July 2023 at 21:04:57 UTC+3, wij wrote:
> > On Saturday, July 8, 2023 at 11:27:47 PM UTC+8, Öö Tiib wrote:
> > > On Saturday, 8 July 2023 at 15:09:16 UTC+3, wij wrote:
> > > > On Saturday, July 8, 2023 at 11:06:28 AM UTC+8, Öö Tiib wrote:
> > > > > On Saturday, 8 July 2023 at 03:57:43 UTC+3, wij wrote:
> > > > > > On Saturday, July 8, 2023 at 4:32:20 AM UTC+8, wij wrote:
> > > > > > > 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.
> > > > > >
> > > > > 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.
> > > > Sounds like a word game.
> > > > You mean the "int read_integer(size_t)" case shown is not error handling?
> > > 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?
> >
> > 'return' in ctor is invalid.
> 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.

[OT] [OT] [OT] Re: C++ error handling -> error is rare -> throw and forget

<u8cgm2$1rdc2$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=736&group=comp.lang.c%2B%2B#736

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: eesn...@osa.pri.ee (Paavo Helde)
Newsgroups: comp.lang.c++
Subject: [OT] [OT] [OT] Re: C++ error handling -> error is rare -> throw and
forget
Date: Sat, 8 Jul 2023 23:24:34 +0300
Organization: A noiseless patient Spider
Lines: 6
Message-ID: <u8cgm2$1rdc2$1@dont-email.me>
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com>
<0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com>
<15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com>
<d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
<648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com>
<ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
<2cbd90d2-d146-4de0-b1d8-4a10b0be697bn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 8 Jul 2023 20:24:35 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b1abbb8f30f353fabe8e09b6e1f85c80";
logging-data="1947010"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+YkLh1pbog6hyH8kAL1p3M6NAslrOK7zA="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.12.0
Cancel-Lock: sha1:YDhmO1fn2EDhY9saDa1Xy3Q0Buw=
Content-Language: en-US
In-Reply-To: <2cbd90d2-d146-4de0-b1d8-4a10b0be697bn@googlegroups.com>
 by: Paavo Helde - Sat, 8 Jul 2023 20:24 UTC

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.

Re: [OT] [OT] [OT] Re: C++ error handling -> error is rare -> throw and forget

<60986588-e4cb-44f8-8395-e740c6c8dee9n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=739&group=comp.lang.c%2B%2B#739

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:4092:b0:762:4cc3:d615 with SMTP id f18-20020a05620a409200b007624cc3d615mr21211qko.5.1688863234042;
Sat, 08 Jul 2023 17:40:34 -0700 (PDT)
X-Received: by 2002:a17:903:2441:b0:1b8:a758:3020 with SMTP id
l1-20020a170903244100b001b8a7583020mr9115002pls.12.1688863233502; Sat, 08 Jul
2023 17:40:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.niel.me!glou.org!news.glou.org!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sat, 8 Jul 2023 17:40:32 -0700 (PDT)
In-Reply-To: <u8cgm2$1rdc2$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=82.131.36.11; posting-account=sCYzwQoAAABXcok-EJve5LuJXPHy2ToN
NNTP-Posting-Host: 82.131.36.11
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com> <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
<648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com> <ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
<2cbd90d2-d146-4de0-b1d8-4a10b0be697bn@googlegroups.com> <u8cgm2$1rdc2$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <60986588-e4cb-44f8-8395-e740c6c8dee9n@googlegroups.com>
Subject: Re: [OT] [OT] [OT] Re: C++ error handling -> error is rare -> throw
and forget
From: vvvvvvvv...@hotmail.com (Man)
Injection-Date: Sun, 09 Jul 2023 00:40:34 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Man - Sun, 9 Jul 2023 00:40 UTC

Kuhu Sul ikka minna siit armsalt planeedilt nimega Maa ?

Mina küll siit minema ei taha minna.

On Saturday, July 8, 2023 at 11:24:51 PM UTC+3, Paavo Helde wrote:
> 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.

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

<73354fd3-61b5-49f4-9422-1cdac8be0cecn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=866&group=comp.lang.c%2B%2B#866

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:1801:b0:403:1d63:dd4f with SMTP id t1-20020a05622a180100b004031d63dd4fmr80298qtc.12.1689542829123;
Sun, 16 Jul 2023 14:27:09 -0700 (PDT)
X-Received: by 2002:a9d:63d1:0:b0:6b9:8ea6:fb02 with SMTP id
e17-20020a9d63d1000000b006b98ea6fb02mr8541590otl.2.1689542828863; Sun, 16 Jul
2023 14:27:08 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 16 Jul 2023 14:27:08 -0700 (PDT)
In-Reply-To: <ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com> <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
<648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com> <ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <73354fd3-61b5-49f4-9422-1cdac8be0cecn@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Sun, 16 Jul 2023 21:27:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3000
 by: wij - Sun, 16 Jul 2023 21:27 UTC

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.

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

<d9f86fcb-4ef2-4b0b-a7e7-defd8054d40bn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=892&group=comp.lang.c%2B%2B#892

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:28c:b0:403:b55e:d4b6 with SMTP id z12-20020a05622a028c00b00403b55ed4b6mr113388qtw.5.1689648170892;
Mon, 17 Jul 2023 19:42:50 -0700 (PDT)
X-Received: by 2002:a9d:7647:0:b0:6b9:a955:43bc with SMTP id
o7-20020a9d7647000000b006b9a95543bcmr11390970otl.3.1689648170421; Mon, 17 Jul
2023 19:42:50 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 17 Jul 2023 19:42:49 -0700 (PDT)
In-Reply-To: <73354fd3-61b5-49f4-9422-1cdac8be0cecn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <bc461974-9613-47c0-b2d8-4536ac7d4ab6n@googlegroups.com>
<0922ce39-3bc2-4b40-a385-22fd11161456n@googlegroups.com> <0a7b2f06-e5e8-48a3-8e96-e59b2a3f0f09n@googlegroups.com>
<cd470560-b15b-4305-a1bb-a7c16f6f0808n@googlegroups.com> <15df8f1a-4925-4c55-9536-41b7ffe60b55n@googlegroups.com>
<536658b2-e142-402d-a54b-6dd9e985b910n@googlegroups.com> <d5fe1c42-a1df-4610-af5e-c5d42c98a666n@googlegroups.com>
<648ae89d-5658-4968-b1ad-4d0f52da541an@googlegroups.com> <ca76783f-c0d9-49a5-ad2b-1f932d4acff1n@googlegroups.com>
<73354fd3-61b5-49f4-9422-1cdac8be0cecn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d9f86fcb-4ef2-4b0b-a7e7-defd8054d40bn@googlegroups.com>
Subject: Re: C++ error handling -> error is rare -> throw and forget
From: wynii...@gmail.com (wij)
Injection-Date: Tue, 18 Jul 2023 02:42:50 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3516
 by: wij - Tue, 18 Jul 2023 02:42 UTC

On Monday, July 17, 2023 at 5:27:20 AM UTC+8, wij wrote:
> 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.

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;
}


devel / comp.lang.c++ / Re: C++ error handling -> error is rare -> throw and forget

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor