But you don't need to check each operation to ensure that none of them overflow. If you know that b and c are supposed to be bounded between -10 and +10, for example, the above line can't overflow. So just check that your supposition holds. In most cases, that boils down to a check on the inputs at the entry of the function.
> Do you prove that every line of arithmetic in your program will not overflow
My point is the analysis takes time, training, and is easy to regress. In practice programs operate within a reasonable N and if you push the limits they will fail. Or the devs wait for a bug report, and then set a pessimistic limit on user input.
Also undefined != crash. Your compiler has options for what to do when signed overflow is detected.
Of course we can speculate if there are ways to mitigate the effects of, instead of avoiding, overflows, if they are free or come with performance penalties, and if the final result is a crash, a graceful exit, or a continued run as if nothing happened, and which is worse.
For the record, I think the answers are: there are, they're not free, and the latter is the worst.