Quote Originally Posted by kmdv View Post
If your point is that in this particular exercise for this particular newbie, the .at() member function is a better choice than assertions, then I agree - all his exception handling is probably one handler printing the error and exiting the program, so it's perfectly fine to leave it for another exercise. However, I don't agree if this is a part of his (even first) application he wants to deploy.
If that's the case, then he/she wouldn't (shouldn't) be a newbie anymore.
If you are going to deploy an application, then you should at least be versed in security, which opens another can of worms of real world problems. In real life, there is never one solution. There are always multiple solutions, and which one is the best depends on the circumstances.

o_O

Since when are assertions "harder to get right" than handling exceptions?
Please show me at least one newbie who is able to properly code a member function which modifies two STL containers at a time and provides strong exception guarantee. Newbies are taught that exception handling is a great way for error reporting. As a result they think of it as a brilliant mechanism, making assumptions that their functions have strong exception guarantee (without knowing this term), leaving everything without proper handling, and then continuing execution of their program to "retry something".

The problem in reporting programming errors via exceptions is that you can accidentally catch such exceptions, and continue execution. You catch "std:ut_of_range" and you think "WTF, what a stupid user entered a bad index!?".
Assertions cause immediate termination and will never change your exception guarantees.
I meant that it's harder to get manual bounds checking right than simply using a member function that's part of a library.
Also, while asserts are nice, they do have a drawback. Assume that you have some long-running operation and you interact with the program meanwhile. Suddenly, you violate a precondition. Should the program crash because of an assert? I sure hope not!
The line between where asserts are good and bad and where exceptions are good and bad aren't easy to know. I would take any exception caught with a grain of salt because it could come from anywhere, even programming errors.