Flood of errors

Am I the only one that sometimes gets a massive flood of errors on the Espruino console, for instance if I accidentally type:

setInterval("$%£^&*()",10);

I always used to detect if there was an error while executing the interval and remove it, but I believe I took that out because if some error happened occasionally then the whole device would just stop working after the first error - when it was actually a lot better to just soldier on.

Is it something you think I should try and stop? Any idea how? I guess I might be able to detect if there were maybe 4 errors in the last second, and if so and another error happens I'd then remove that interval/watch.

Yeah, it is very painful when that happens. I usually try testing all my intervals with a bigger time periods initially.

I wouldn't want removal of the internal/watch unless it were a configurable/toggleable feature and/or it logged somewhere or called an error handler. It'd be very frustrating to set up a project, walk away, then when checking it later find out that it stopped working and you don't know why.

I would really want a way to disable this if it were done. While my intervals shouldn't be spewing errors, I'd like a way to set it to keep soldiering on - partial functionality may be better than

There's a special case that is particularly troublesome here though, and which your solution doesn't fix - and that is the case of things like network requests and I2C failures that block. In this case, you end up with the queue filled with error events that each block for like 30 seconds until they time out - by which time several more such intervals have entered the queue, and I've often had a hard time breaking out of it with ctrl+c. This is really unpleasant, and it happens in response to just about every wiring error in I2C, plus malfunctioning devices (my BMP180's always do that as soon as I close the project box and try to use it, and I've tried them mounted like 3 different ways, 4 different units, on every I2C bus, and they always work on the bench and then almost immediately fail when I set them running... but I digress).

Actually, what do you think about adding a timeout option to I2C.setup()? With, like, almost all I2C devices, if it isn't responding within a few milliseconds, giving it another 30,000 ms isn't going to make a difference, and it would be nice even just for the sake of speed in debugging to not have to wait through an unnecessarily long timeout... Or maybe the current timeout should just be shortened? Should it ever take that long for an I2C device to respond?

Hmm - interesting... what about doing it only if it were on a USB connection (with the console also on USB)? Because then it's going to crash anyway if nothing is there to read the messages, and if it is, you probably don't want to get spammed either.

it happens in response to just about every wiring error in I2C

There was a 'bug' in the Pico where the timeouts were crazy long. I hope I've fixed that now - however you're right, the timeouts should be way shorter across the board. From what I can tell, as short as 1ms seems ok - anyone know better?

If there's something reproducable that you can't break out of with Ctrl-C then can you let me know? I should be able to fix those.

I guess if you break out of an interval with Ctrl-C, it should maybe kill that interval?

Ctrl+c killing intervals sounds good. Personally, that'd fix it for me.

I guess it doesn't help in the original case where execution stops almost immediately (as the chances of Ctrl-C being hit during execution are tiny), but I guess I could do something like:

executeInterval();
if (wasError or Ctrl-C pressed during execution) {
  reportError();
  if (Ctrl-C last pressed less than 0.5 sec ago)
    removeInterval();
}

Hopefully that would work out?

Just another thought though: What if there's no error but you still want to break out?

setInterval(function() {
  print('Oh No!');
}, 0);

Maybe the correct logic is just:

executeInterval();
if (Ctrl-C pressed less than 0.1 sec ago) {
  removeInterval();
}

Ok, just done that last thing, and it seems to do what you expect without really getting in the way.

Logic now looks a bit like:

executeInterval();
if (Ctrl-C pressed or lastCtrlC > getTime()-0.1) {
  removeInterval();
}

//... in idle loop:
if (Ctrl-C pressed) {
  if (input line not blank) clearInputLine();
  else lastCtrlC = getTime();
}

So if you've got an interval that works every second, pressing Ctrl-C probably won't break out of it. Instead you'll have to just hold it down around the time you expect the interval to occur.

Latest build will be here in about an hour:

http://www.espruino.com/binaries/git/commits/b9d68d653148afff652b23e72588b915eac1f9d4

Only just got a chance to check this out. It works great! The notifying message is helpful.