(I have long gap to communicate with C++ and do not recall if I have used 'try-catch' at all; so, looking for advice...)

I am trying to understand what the benefits of using that C++ error handling style compare to regular C-style 'if-then'?

Still in the try{} block need to do some 'if()' to be in error condition and 'thtow()' it;
Still need to have separate block to act on defined error condition - so, the same as in block of 'if (error) {.... }'

Only additional funny syntax, blocks and lines of code...

Am I do not understand something or just do not see some benefits?

What the advantage?

Can anybody tell me that in short?
I would accept any: processing timing/simplifying; readability; source organizing; documenting; modularity, .... what else?
I do not see any!

In my opinion try catch is easier to express and more readable. Yes, you can create multiple if else blocks, but for try catch there are only two blocks (try and catch). Another feature of expressing errors in terms of exceptions is that, you can add a new exception very fast. Getting an exception object, with the proper error message is much better than getting an error code and going through the manuals to find what the error actually is. The latter is very useful, when the error is thrown by some code which we did not write (for eg library). The exception object could even contain some status information and so on, which might help in debugging. Also it is easier to group exceptions, using exception type

I have seen people talking about performance. When a try catch code is written, the assumption is that, the event of an error is unlikely. Hence the compilers usually optimize the code to only jump when an error occurs (to catch block). Where is in the case of if else, the compiler has no idea of which block should be given preference. If called multiple times, usually this gap wont be visible as the branch prediction mechanism should take care of this.

However exceptions in c++ has some disadvantages. Like stack unwinding issues, breaking the object construction (if an exception is raised inside a construction)

The try/catch construct is used primarily to catch errors that are either:

Caused by a coding error (such as a divide by zero), or

Occur in a procedure that your code calls (such as a library procedure)

In general, you are correct that you should be using if blocks to test for, and handle, any errors that you can detect. For example, you could test for a zero denominator before you perform a division.

However, you probably don't want to throw an exception for errors that you detect and handle. You're correct that you can deal with such errors more easily (and, actually, with more readable code) in line.

On the other hand, throwing an exception can be an excellent way to signal to a caller that an error has occurred. That way, if the caller hasn't performed all the necessary testing before calling your code, or if the error is something that the caller can't test for (such as a missing file needed only within your code), the caller can catch any "unexpected" errors.

Rule One: Always check the parameters passed to your method or function before using them (if-then). If they are unsuitable, you can either return an object or value that indicates that nothing was done (null, zero, etc.) or you can throw an exception indicating that the parameters are not acceptable and why.

Rule Two: Check the documentation of any method or function you call to see if it throws an exception. If it does, you have a decision to make: do you handle it in your method or function or do you allow it to be propagated up the call stack. If you choose to handle the exception, then you need a try/catch block.

Rule Three: throw an exception when there is a critical error: don't hide or mask the critical error (e.g. cannot open a file, cannot connect to a service, etc.)

Rule Four: When handling an exception and letting it propagate up the call stack, do not create a new exception and throw it. Instead, throw the exception you caught to preserve the call stack, allowing for more accurate debugging.

These 'rules' are just a few of the many that are considered good practice.