Typescript: static return might fail with switch statement

Created on 25 Apr 2018  路  7Comments  路  Source: microsoft/TypeScript

I have this:

const onUpdate = function (v: string, o: any) : Promise<any> {

  const finalName = String(v || '').split('.')[1]; // collection name
  const _id = o && o.o2 && o.o2._id;
  let key;

  switch (finalName) {

    case 'categories':      
      return Category.findOne({_id}).exec().then(function (cat: any) {
         // ....
      });

    case 'acquisitions':
        return Acquisition.findOne({_id}).exec().then(function (acq: any) {
         // ...
      });

    case 'functionalTeams':
      return FunctionalGroup.findOne({_id}).exec().then(function (ft: any) {
           // ...
      });

    default:
      log.error('document collection did not match a pre-defined name');
      // nothing is returned here, but can TS check to see if it does/doesn't
  }

};

can TypeScript check to see if a Promise fails to be returned in the default or after the switch statement? Right now it's compiling even though a Promise is not returned in all cases.

Question

All 7 comments

You probably just need --strictNullChecks enabled.

Or alternatively --noImplicitReturns. Enabling --strictNullChecks is often very difficult to add in old code bases, but --noImplicitReturns is a no-brainer.

@andy-ms yeah that's fine, I guess I would expect the default behavior to always catch this one tho?

The default behaviour is to align with JavaScript. If a function returns "nothing", it implicitly returns undefined. That is what is happening here. And with strictNullChecks disabled, the value of undefined is compatible with the type Promise<any>, the value is compatible with any type.

strictNullChecks will change the semantics of undefined from a mere value to a type, so the value undefined will be of the type undefined, which is not compatible with Promise<any> anymore. You will get an error.

noImplicitReturns will enforce what the name implies: A method may not have an implicit return value. That means you have to explicitly write return undefined;.

ok understood, to move this in a more productive direction, is there a way to never allow null/undefined in the place of a defined value? In Java, all those NullPointerException's are caused by allowing null to exist in far too many places.

Returning null from a function/method instead of an array or Promise, or anything, it's just crazy imo.

Yes... That is pretty much what strictNullChecks is for. And related to that the strictPropertyInitialization feature (works only together with strictNullChecks.

@MartinJohns thanks for the info...I still think strictNullChecks should be the default behavior, and that users should have to specifically set it to false, but nbd I guess

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Roam-Cooper picture Roam-Cooper  路  3Comments

jbondc picture jbondc  路  3Comments

uber5001 picture uber5001  路  3Comments

kyasbal-1994 picture kyasbal-1994  路  3Comments

seanzer picture seanzer  路  3Comments