Bug with clearTimeout()?

If I call

clearTimeout(undefined);

all intervals set by setInterval() and all timeouts set by setTimeout() disappears.
Checked by 1v95 on ESP8266

Is it a bug?

If you have a problem with ESP8266 boards:

1. Read the documentation first, since it explains exactly how the function works.
   
2. If that doesn't help, please post on the ESP8266 section of the forum. Not the one titles Official Espruino Boards with the sticky post saying This forum is for Official Boards only right at the top.
   

Thank you.
I think I have asked my question in bad form.
I know about clearTimeout() without arguments.
But I call it with 1 argument. But the argument is undefined. And I see the same result. I do not know if it is a bug or not.
For example:

var timNum;
clearTimeout(timNum);
timNum=setTimeout(.....);

And I think it depends on JS implementation does on all devices, not only ESP8266. Usually I try to test my code for Puck.JS with ESP8266 first, because it is much easier to connect peripherals to it and to send code to it as well - espruino-server falls each second connection and can not work together with EspruinoHub.

Hi SergeP,

as Gordon pointed out: Read the documentation first
there is no return for setTimeout()

Guess you are looking for setInterval().

@MaBe The documentation to setTimeout states:

Returns An ID that can be passed to
clearTimeout

To answer your question calling a function without an argument is identical to calling it with undefined

mea culpa, how could I miss that 😳..... thanks to AntiCat

Hi - sorry about the short reply earlier @SergeP.

You're totally correct that they're the same on different platforms. The two forum sections are mainly there for me - over half of Espruino's users are using it on non-official boards now, and I can't afford to provide the same level of support for those that I provide for the boards that I sell (it's also one less reason for people to buy a proper board :). I'd forgotten that you were using Puck.js as well. If you hit issues like this again feel free to post on the official boards page, but please check it on a Puck or official board first just in case :)

In some cases it is possible to detect an undefined argument (eg. checking arguments.length), but for most built-in functions this isn't done as it's slower/more complicated. The clearInterval(undefined) is intended behaviour - but it is a bit of a design flaw. I've hit bugs caused by it a few times myself too.

It seems that making clearInterval(undefined) throw an exception while clearInterval() works might help to make errors far less likely? What does everything think?

It seems that making clearInterval(undefined) throw an exception

Seems like a clean solution.

My vote is making it behave consistently with the spec.

Passing an invalid ID to clearTimeout() silently does nothing; no
exception is thrown.

https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/clearTimeout

Passing undefined or no parameters to clearTimeout should do nothing.

I vote for handling undefined and missing the same way. Default function parameters are implemented in javascript using a check for undefined - an example:

function multiply(a, b) {
  b = (typeof b !== 'undefined') ?  b : 1;
  return a * b;
}

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters

I believe adding a distinction between undefined and missing breaks the spec too.

@AntiCat Thanks, exactly.

@SergeP @Gordon I don't think this is a bug but rather a feature that the Espruino cleanInterval() implementation deviates from the specified behaviour by cancelling all scheduled timeouts and intervals rather then doing nothing.

That said unless we would like to change the behavior to comply to the spec which would break a lot of existing user code done specifically for Espruino (perhaps doable using some sort of deprecation mechanism).

Hmm - I'm still not convinced that () vs (undefined) is breaking the spec - look at console.log() vs console.log(undefined) - they do different things.

Ideally it'd be spec compliant but given there's so much code out there that uses it, and changing it to be spec compliant would just 'silently do nothing' which would just randomly stop Espruino code from working with no warning - I don't think going fully spec compliant is an option.