ChatGPT解决这个技术问题 Extra ChatGPT

Why do TSLint and JSLint report empty blocks?

From time to time, I get TSLint errors "block is empty". This happens e.g. when I pass a no-op callback to a function:

doSomething(() => {});

From what I read, JSLint apparently does the same, but I didn't verify that.

I find these usages completely valid, so I tried to find a reason why empty blocks are considered bad at all. But the only thing I'm able to find (e.g. in this answer) are instructions to add a return; to avoid the error. This is not what I want to do in every empty callback.

Why does TSLint report above empty block as problem? Is there any reason why I shouldn't disable the check?

Never used either; just thinking aloud: could it be that the times that TSLint complains is when it thinks the function should return a value and your no-op function isn't doing so? You could perhaps define an explicit no-op function and just pass its name in this sort of call.
@TripeHound No, TSLint complains even when I specify an explicit type of (() => void) for the callback. Regarding the noop: I just found out that lodash already defines one: _.noop. This is so far the cleanest solution...
@danwellman yes but that changes the return type from void to an empty object.
Go to the following page for the empty function errors: stackoverflow.com/a/70746269/7680511
Go to the following page for the empty function errors: stackoverflow.com/a/70746269/7680511

b
basarat

Why does TSLint report above empty block as problem

To prevent mistakes. Perhaps the function was forgotten to be filled out. Recommend () => undefined as a noop.

More

If you want to disable it simply add "no-empty": false, to your tslint.json (globally disable) or disable it inline using a /* tslint:disable:no-empty */ comment.


I guess I don't want TSLint to tell me I missed filling out a function body, that's what I have tests for. So if there is really nothing else that this check is useful for, I rather disable it than using () => undefined in every single callback. But that's a matter of taste I suppose.
Just to clarify, could you specify what you mean by "mistakes" exactly? Is it just the empty function body?
Like basarat said, a mistake might be you forgot to implement something, although conventionally every function you want yo implement someday should throw NotImplemented when used.
s
spacedev

If you feel you dont want to use callback during certain scenarios you can modify the code

from

doSomething(() => {});

to

doSomething(() => undefined);

Substituting () => {} to this implies you dont care about this callback. and explicit typecasting will avoid implications.

Good luck.


F
Fenton

As with all checks, you have the ultimate judgement on whether they are helping you or not. You can switch off this TSLint check using one of the following options.

Disable the rule in tslint.json

//...
"no-empty": false,
//...

Disable the rule in the file:

/* tslint:disable:no-empty */

You can always switch it back on again if sometime in the future you find an empty block that has caused you a problem.


E
Estus Flask

A way to suppress the error and designate that empty block was intentionally is to disable the rule temporary:

// tslint:disable-next-line:no-empty
doSomething(() => {});

Or make it non-empty:

doSomething(() => {/**/});

The second advise seems very inappropriate.
T
Tomas Varga

tslint v5.10.0 introduced "allow-empty-functions" option to "no-empty" just for this case;
also "allow-empty-catch" (introduced in v5.5.0) may be useful:

"no-empty": [true, "allow-empty-functions", "allow-empty-catch"]