The problem with the above code is without exceptions you know where the program failed 23843 or 28783 but with exceptions all you know is something is wrong.
bzzt. depending on the language and the author of the exception-throwing code, the exception will contain information about where the error occurred and what might have caused it.
True, but in the above code such information is not propagated outside of the function. If you want to add that you need to throw another exception inside of the catch block or skip the catch.
At this point, I'm tired of typing the code. Checking for errors after every function call is way too much work
Think of what the exception code ends up as in ASM. Basically try transparently wraps system calls with the same type of error handling code as his example. However, if you want to write stable code you need to account for each of these errors anyway. So when your DB connection fails you need to know if it’s a TCP/IP error or a Bad Password etc which means either wrapping each line with its own try catch or decoding the exception within a catch block. Granted, exception handling let’s your write code for the ideal case and avoid crashing when something messes up but as soon as you want to recover from an error without starting over you end up writing the same code anyway. And because the happy path works it’s not obvious just how far you are from high quality code.
catch database error {
warn "Whoa, your database is broken!";
}
Ignores all that and hides the error. I only point this out because I have seen a lot of real world code where people skip even the assert in the catch statement.
Edit: You can add all of this stuff manually (or as part of the warn function) but I would like to see a language where you can define a standard place where all errors are logged independent of the given code unless it’s explicitly overridden. So you people can't add empty catch blocks.
