This is what we call raising an exception.

> I add that the desired behavior can always be implemented using regular control flow constructions.

I agree. But that's not a very interesting observation. We added language specific constructs for errors not for the computer but for the human. These constructs make reading and writing code easier and safer.

A code with if-else constructs for every possible error condition is really hard to follow and very brittle. If the result of every error condition is the same (stop doing things) we have developed constructs to make that path easy.

The problem with errors is that understanding and resolving them is often non-local. If a network call fails the code where that fail happens doesn't have enough information to resolve it. If the solution is re-try the entire operation 3 times and then give up, the handling of this error must happen back where the operation starts not some random place in the middle where it actually occurred. Maintaining all the if/else necessary to move that information up through potentially dozens if not hundreds of calls is extremely difficult. And, it turns out, completely unnecessary and easily automated.