Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Sun, 08 Jun 2025 02:43:25 +0800
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <1858c98adc50b2bec4021f15d0c5b94e2158f6b5.camel@gmail.com>
References: <100h650$23r5l$1@dont-email.me> <101ft3d$1feqh$2@dont-email.me>
	 <101gq6l$1rdgj$1@raubtier-asyl.eternal-september.org>
	 <101h0an$1tkqk$1@dont-email.me>
	 <101jk7i$34erh$1@raubtier-asyl.eternal-september.org>
	 <1nj%P.3454$mAv4.2422@fx34.iad>
	 <101nc3o$5pjd$1@raubtier-asyl.eternal-september.org>
	 <h6H%P.676329$McHf.348392@fx15.iad>
	 <101u8sb$25g28$1@raubtier-asyl.eternal-september.org>
	 <3FC0Q.931590$G6Lf.397684@fx17.iad>
	 <101v7d7$2cudl$1@raubtier-asyl.eternal-september.org>
	 <CvF0Q.1165311$McHf.1120306@fx15.iad>
	 <101v8ce$2d5it$1@raubtier-asyl.eternal-september.org>
	 <0e9619f7d873a4ec436f017bac1192c73c5283e5.camel@gmail.com>
	 <1020eu8$2pifl$1@raubtier-asyl.eternal-september.org>
	 <1e3f53801e22a94356b9b0aded0ed7d33e67fd06.camel@gmail.com>
	 <1021pgp$35sqk$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 07 Jun 2025 20:43:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9bd70c4a0c87ec4ace2a3a7ed7005e97";
	logging-data="3366792"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1809FWtAwYU0p6N4KfRte8c"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:Wt+8bVNfO8YOHAq2Xi51O8Z7dco=
In-Reply-To: <1021pgp$35sqk$1@raubtier-asyl.eternal-september.org>
Bytes: 3986

On Sat, 2025-06-07 at 18:31 +0200, Bonita Montero wrote:
> Am 07.06.2025 um 13:58 schrieb wij:
>=20
> > C++ is no better, probably worse. Firstly, the term 'exception' (and
> > 'vector' probably) is disabled in human mind to think about exception.
>=20
> I deal with exceptions every day and I've no problems with that. C++
> exceptions aren't that clean like Java exceptions, but still make much
> less work than C return code handling.

The error from opendir(..):

       EACCES Permission denied.
       EBADF  fd is not a valid file descriptor opened for reading.
       EMFILE The  per-process limit on the number of open file descriptors=
 has
              been reached.
       ENFILE The system-wide limit on the total number of open files has  =
been
              reached.
       ENOENT Directory does not exist, or name is an empty string.
       ENOMEM Insufficient memory to complete the operation.
       ENOTDIR name is not a directory.
       ...

Those are just common errors, there are actually more, and more from subseq=
uent
read/write/.... File operations (particularily directory) are actually very=
 nasty.

I think your 'less work' was from simplication or idealization, lots are=
=20
simplified and idealized. =20
We have no problem is because our average programs don't need to handle tho=
se=20
individual errors, but C's major task is to build OS, not average applicati=
ons.

> > C++ had been trying to HIDE error (exception) from its beginning, very =
wrong
> > and very unsuccessful.
>=20
> Exceptions are the cleanest way of error handling.=C2=A0

Conditional. As said 'simplified'.

> In most cases you
> deal with the error in a higher function and not in the leaf of the
> call graph; therefore exceptions are perfect.

If you can handle errors that way, C can also do it in much simpler way.
The basic problem of throwing error is losing error context, it is similar
to set a global errno (or object) and cause the program to stack unwind.

C++ has many artificial fancy things and encourages such programming style.
Good or bad? Both, but I would say mostly bad.