How could you ever continue after the second statement without checking if you actually read an integer or not? How would you know what you can do with a?

You couldn't or wouldn't. but why have a read statement like cin>> which looks so nice and clean when you then have to go and check everything with flags and boolean casts on stateful objects.

I agree. It's lunacy. just be explicit and use functions or equivalent like literally every other language.

Well in a language like Haskell you could solve this with monads and do-notation. The general idiom in Haskell is to use a Maybe or Either monad to capture success/failure and you assume you’re on the happy path. Then you put the error handling at the consumer end of the pipeline when you unwrap the Maybe or Either.

I believe Rust has adopted similar idioms. I’ve heard the overall idea referred to as Railway-oriented programming.

In C++ you could implement it with exceptions, though they bring in a bunch of their own baggage that you don’t have to deal with when using monads.

You’re holding it wrong. Like nan, the point is you don’t have to error check every operation.

You check error for the whole batch.

   fscanf (STDIN, "%d", &a);

the program goes beserk as soon as the first non-number is read out of standard input.

in both cases, you need error checking (which you "know about").

No actual C programmer who has been around the block more than halfway should do that. The mantra is: "read into a character buffer, then parse that".

It's more code, sure, but it buys you a lot of good things. I/O is hard.

No C++ programmer who has been around the block more than halfway should do

    cin >> a;

and assume that it works.

But also ...

    sscanf (the_buffer, "%d", &a);

doesn't help the problem in any substantive way.