94

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?

Community
  • 1
  • 1
theDmi
  • 17,546
  • 6
  • 71
  • 138
  • 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 Jul 24 '15 at 08:51
  • 1
    @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... – theDmi Jul 24 '15 at 09:32
  • @danwellman yes but that changes the return type from `void` to an empty object. – Patrick Roberts Oct 20 '18 at 02:17
  • Go to the following page for the empty function errors: https://stackoverflow.com/a/70746269/7680511 – William Hou Jan 17 '22 at 19:57
  • Go to the following page for the empty function errors: https://stackoverflow.com/a/70746269/7680511 – William Hou Jan 17 '22 at 20:06

6 Answers6

161

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.

basarat
  • 261,912
  • 58
  • 460
  • 511
  • 3
    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. – theDmi Jul 24 '15 at 09:35
  • Just to clarify, could you specify what you mean by "mistakes" exactly? Is it just the empty function body? – theDmi Jul 24 '15 at 09:36
  • 2
    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. – MikeSW Jul 24 '15 at 13:39
  • FYI it's been updated to: "no-empty": 0, – Alex Aug 29 '22 at 20:26
  • Using `() => undefined` breaks the [no-undefined](https://eslint.org/docs/latest/rules/no-undefined) rule, so no this is not recommended. The recommended fix is to [write a clear comment](https://eslint.org/docs/latest/rules/no-empty-function): `() => {\n// Do nothing.\n}`. – Géry Ogam Apr 28 '23 at 14:15
39

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.

spacedev
  • 1,086
  • 13
  • 13
15

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(() => {/**/});
Estus Flask
  • 206,104
  • 70
  • 425
  • 565
13

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.

Fenton
  • 241,084
  • 71
  • 387
  • 401
  • Avoid disabling lint rules. – angellica.araujo Oct 20 '22 at 08:59
  • 1
    @angellica.araujo you should absolutely build your own ruleset with your team. Don't follow lint rules blindly. I would keep this particular rule, but in general, you should _think_ about each rule and take a team decision. – Fenton Oct 25 '22 at 17:44
  • I understand your point. The thing is that ideally, the decision to build the ruleset usually occurs when the project starts. You may help me to understand why investing time to choose a ruleset that can be easily bypassed or ignored (as the first option to solve issues like the one mentioned) while a project grows. – angellica.araujo Oct 26 '22 at 13:39
7

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"]
Tomas Varga
  • 1,432
  • 15
  • 23
1

if it doesn't work the comment inline to disable try this

// eslint-disable-next-line @typescript-eslint/no-empty-function
handler: () => { }, // here you empty function
Martinez
  • 131
  • 4