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.
I meant that it's harder to get manual bounds checking right than simply using a member function that's part of a library.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.
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.