Re: encapsulating directory operations

On 2025-06-08, Scott Lurndal <scott@slp53.sl.home> wrote:

Muttley@DastardlyHQ.org writes:

On Sun, 8 Jun 2025 17:02:08 +0200
Bonita Montero <Bonita.Montero@gmail.com> wibbled:

Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:
>

You can of course use setjmp & longjmp in C but depending on how many levels
up you jump they could be more trouble than they're worth. I think I've only
ever used them once.

>
That's makes a lot of work and it's really ugly. And you need global
jump_buf-s for that.

>
Its no different to C++ exceptions except obviously no destructors are called
so there's no chance to do a tidy up at each stack level. Also jumps arn't
limited to lower to higher stack frames jumps, they can jump about all over
the place. Whether thats useful or not I can't say. I've never needed it.
>

>
I've used sigsetjmp/siglongjmp in C++ code, very successfully.   As an experiment a few
years ago, I replaced it with C++ exceptions and took a 20% performance
hit in the application.    Needless to say the experiment was a failure.

setjmp and longjmp have a clearly defined implementation model
(obviously not in ISO C, but so in implementation practice).

Implementations of setjmp do not stray far from the paradigm of just
saving a bunch of registers in an array, which are then 'blindly"
restored.

This model gives you certain performance characteristics that you can
rely on. Both saving the state and doing the longjmp are fairly cheap.

In C++, the tradeoffs are going to be a crapshoot: whether it is
expensive to set up a try block, but cheap to throw, or vice versa
and that sort of thing.

A C++ throw typically has to search for the exit point to which control
will be transferred. (Maybe not in some statically analyzable cases,
like throw and catch being all in the same function.)

In general, I tend to concur with wij - I prefer to handle run-of-the-mill
errors when they're detected.

But errors can't always be handled where they are detected.  That's why,
in the first place, you are receiving the error from the function that
failed! That function couldn't handle it, so it tossed it upward to you.

The alternative to exceptions is to detect errors at multiple levels
and pass up whatever you can't handle.

>
For example:
>
c_file_card_unit::c_file_card_unit(ulong channel, ulong unit, const char *name,

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

OK, this is a constructor.

So, if is_ready() returns false after the constructor runs,
the creator of the object knows the creation failed.

Right, just like the caller of open() knows that creation
failed, because -1 was returned.

The error was only partially handled by c_file_card_unit in so far
is that it ended up in a documented state, which now something
else has to handle.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca