Hacker News Reader

Comment by ElViajero | Hacker News Reader

> On Error Resume Next takes an approach that’s the worst idea in many error situations

Does this mean that this feature should not exist? Or that it may be misused?

It seems just a kind of rough Java 'try-final'. If you know that an access to disk, e.g., may fail 'resume on next' just guaratees that the rest of code is executed.

This would not be so wise in a language like C++ were you may have corrupted the stack. But, for basic it had its uses.

View on HN

On Error Resume Next is like if every statement was automatically wrapped in a try/catch that ignores the error.

Obviously there are some cases where it makes sense to ignore errors, but doing it unconditionally for all errors is horrible.

You could still examine the Err variable to see if an error happened.

Yeah, the legions of VB programmers who just wrote On Error Resume Next at the beginning of the file and never looked back weren’t keen on doing that, either.

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.

The only sane use of On Error Resume Next is surrounding one or two specific lines of code where you dont want to let the ordinary exception mechanism be triggered. For larger blocks of code it's completely insane.

Its problem is not that it exists, but that it’s a separate statement. In most languages, if you write try, you have to write catch or finally for your program to even start running.

If you write on error resume next, you should revert that soon, but the language doesn’t prevent you from forgetting to do that. Neither, AFAIK, do typical editors. A good editor, IMO, would indent code inside a “on error resume next”, but I haven’t seen such editors.

It does help that its scope ends at function/procedure return (I think), but of course, that means seemingly benign refactoring can change program behavior.

It isn’t too bad when you write new code, but once you start maintaining a larger program, it can bite you.

Ehhhh, I mean it's conceivable that there were some reasonable use cases for it, but in reality it was just a massive foot gun. I remember trying to debug some old VB6 code in the late 90s that used On Error Resume Next all over the place, and it would get into some unbelievably funky states, it was a miracle that it worked even some of the time. The truly scary thing about it was that even some system level errors would just get swallowed up and you had no idea that Really Bad Things(TM) were happening under the hood.

The equivalent to try/catch in VB was On Error Goto <ErrorHandlerLabel> which when used properly was more or less fine.

A much nicer version of this is the Common Lisp condition system. Roughly the way it works is that in addition to being able to raise exceptions, a procedure can ask a condition handler how to proceed. Basically, the condition handlers are dynamically scoped like a try/catch, and the conditions can be finer-grained than a catch-all Error (though to be somewhat fair to Visual Basic, you could also "On Error GoTo handler_label").

Here's how it might look in Python:

  try:
    f = open("foo.txt")
    s = f.read()
  condition FileNotExists as c:
    handle UseStream(io.StringIO(""))

where when open fails to find a file, Python will look for the first FileNotExists condition handler, pass it a FileNotExists condition object, and then the handler can choose to handle the condition.

On the open side, it could be something like this:

  def open(filename):
    restartable:
      ... low-level stuff to open the file ...
      if failed:
        signal FileNotExists(filename)
      ...
    restart UseStream as r:
      return r.stream

It makes sense for a batch of simple commands that could be run in parallel.

A very simple startup or autoexec script for example, where it might be useful for the rest of the tasks to be done even if one of them fails. It assumes no dependencies between the tasks.

It’s like wrapping every single statement inside a try: clause, with final: continue.

Reply on news.ycombinator.com