Having done some Visual Basic with that a long time ago, the problem with it is that its not fine grained and there's no easy way to know if something failed. F

Having done some Visual Basic with that a long time ago, the problem with it is that its not fine grained and there's no easy way to know if something failed. For example, you have a large procedure with a division by zero somewhere in it, the code will just continue and you will never know, nor have a way to detect it. But often, if an error happens, the rest of the code will also be errors (or just be incorrect), so continuing to the next statement just masks the error, it doesn't do anything to handle it. I don't remember what happens in case of a file access failure: is there a way to detect that there was an error? (Other comment below suggests yes, but it sounds rather brittle to have to check the Err object after every statement) But if so, why not just check for errors without 'on error resume next'. At least with try-finally, you get to choose the scope of it, so you isolate the part where an error might occur that you wish to resume after.