Never-tyyppi: Siirtyminen suoritusaikaisista virheistä käännösaikaisiin takeisiin

Ohjelmistokehityksen maailmassa käytämme merkittävän osan ajasta ja vaivasta virheiden estämiseen, löytämiseen ja korjaamiseen. Osa salakavalimmista virheistä on niitä, jotka ilmenevät äänettömästi. Ne eivät kaada sovellusta välittömästi; sen sijaan ne piiloutuvat käsittelemättömiin reunatapauksiin odottaen tietyn datan tai käyttäjän toiminnon laukaisevan virheellisen käyttäytymisen. Yleinen tällaisten virheiden lähde on yksinkertainen unohdus: kehittäjä lisää uuden vaihtoehdon valikoimaan, mutta unohtaa päivittää kaikki ne kohdat koodissa, joiden on käsiteltävä sitä.

Oletetaan, että `switch`-lause käsittelee erilaisia käyttäjän ilmoituksia. Kun uusi ilmoitustyyppi, sanotaan 'POLL_RESULT', lisätään, mitä tapahtuu, jos unohdamme lisätä vastaavan `case`-lohkon ilmoitusten renderöintifunktioomme? Monissa kielissä koodi yksinkertaisesti putoaa läpi, ei tee mitään ja epäonnistuu äänettömästi. Käyttäjä ei koskaan näe kyselyn tulosta, emmekä ehkä löydä virhettä viikkoihin.

Entä jos kääntäjä voisi estää tämän? Entä jos omat työkalumme voisivat pakottaa meidät käsittelemään kaikki mahdollisuudet muuttaen mahdollisen suoritusaikaisen logiikkavirheen käännösaikaiseksi tyyppivirheeksi? Juuri tämän voiman tarjoaa 'never'-tyyppi, käsite, joka löytyy moderneista staattisesti tyypitetyistä kielistä. Se on mekanismi tyhjentävän tarkistuksen varmistamiseksi, tarjoten vankan, käännösaikaisen takuun siitä, että kaikki tapaukset käsitellään. Tämä artikkeli tutkii `never`-tyyppiä, vertaa sen roolia perinteiseen virheidenhallintaan ja osoittaa, kuinka sitä voidaan käyttää joustavampien ja ylläpidettävämpien ohjelmistojärjestelmien rakentamiseen.

Mikä 'Never'-tyyppi oikeastaan on?

Ensi silmäyksellä `never`-tyyppi saattaa vaikuttaa esoteeriseltä tai puhtaasti akateemiselta. Sen käytännön vaikutukset ovat kuitenkin syvällisiä. Ymmärtääksemme sen, meidän on ymmärrettävä sen kaksi pääominaisuutta.

Tyyppi mahdottomalle

`never`-tyyppi edustaa arvoa, jota ei voi koskaan esiintyä. Se on tyyppi, joka ei sisällä mahdollisia arvoja. Tämä kuulostaa abstraktilta, mutta sitä käytetään ilmaisemaan kahta pääskenaariota:

1. Funktio, joka ei koskaan palauta: Tämä ei tarkoita funktiota, joka ei palauta mitään (se on `void`). Se tarkoittaa funktiota, joka ei koskaan saavuta päätepistettään. Se saattaa heittää virheen tai se saattaa mennä loputtomaan silmukkaan. Tärkeintä on, että normaali suoritusvirta keskeytyy pysyvästi.
2. Muuttuja mahdottomassa tilassa: Loogisen päättelyn (tyypin kaventamiseksi kutsutun prosessin) avulla kääntäjä voi määrittää, että muuttuja ei voi sisältää mitään arvoa tietyssä koodilohkossa. Tässä tilanteessa muuttujan tyyppi on käytännössä `never`.

Tyyppiteoriassa `never` tunnetaan pohjatyyppinä (usein merkitty ⊥). Pohjatyyppi oleminen tarkoittaa, että se on alityyppi kaikille muille tyypeille. Tämä on järkevää: koska tyypin `never` arvoa ei voi koskaan olla olemassa, se voidaan määrittää tyypin `string`, `number` tai `User` muuttujalle tyyppiturvallisuutta rikkomatta, koska kyseinen koodirivi on todistettavasti saavuttamaton.

Ratkaiseva ero: `never` vs. `void`

Yleinen sekaannuksen aihe on ero `never`- ja `void`-tyyppien välillä. Ero on kriittinen:

• void: Edustaa käyttökelpoisen paluuarvon puuttumista. Funktio suoritetaan loppuun ja palauttaa arvon, mutta sen paluuarvoa ei ole tarkoitus käyttää. Ajattele funktiota, joka vain kirjaa konsoliin.
• never: Edustaa palauttamisen mahdottomuutta. Funktio takaa, että se ei suorita suorituspolkuaan normaalisti loppuun.

Katsotaanpa TypeScript-esimerkkiä:

            // Tämä funktio palauttaa 'void'. Se suoritetaan onnistuneesti loppuun.
function logMessage(message: string): void {
  console.log(message);
  // Palauttaa implisiittisesti 'undefined'
}

// Tämä funktio palauttaa 'never'. Se ei koskaan suoritu loppuun.
function throwError(message: string): never {
  throw new Error(message);
}

// Tämä funktio palauttaa myös 'never' loputtoman silmukan vuoksi.
function processTasks(): never {
  while (true) {
    // ... käsittele tehtävää jonosta
  }
}
            

              
                Copy
              
            
          

Tämän eron ymmärtäminen on ensimmäinen askel `never`-tyypin käytännön voiman avaamiseen.

Ydin käyttötapaus: Tyhjentävä tarkistus

`never`-tyypin vaikuttavin sovellus on tyhjentävien tarkistusten varmistaminen käännösaikaisesti. Sen avulla voimme rakentaa turvaverkon, joka varmistaa, että olemme käsitelleet kaikki tietyn tietotyypin variantit.

Ongelma: Haavoittuva `switch`-lause

Mallinnetaan geometristen muotojen joukko erotetun unionin avulla. Tämä on tehokas malli, jossa sinulla on yhteinen ominaisuus (erotin, kuten `kind`), joka kertoo, minkä tyyppivariantin kanssa olet tekemisissä.

            type Shape =
  | { kind: 'circle'; radius: number }
  | { kind: 'square'; sideLength: number };

function getArea(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      return Math.PI * shape.radius ** 2;
    case 'square':
      return shape.sideLength ** 2;
  }
  // Mitä tapahtuu, jos saamme muodon, jota emme tunnista?
  // Tämä funktio palauttaisi implisiittisesti 'undefined', todennäköisen virheen!
}
            

              
                Copy
              
            
          

Tämä koodi toimii toistaiseksi. Mutta mitä tapahtuu, kun sovelluksemme kehittyy? Kollega lisää uuden muodon:

            type Shape =
  | { kind: 'circle'; radius: number }
  | { kind: 'square'; sideLength: number }
  | { kind: 'rectangle'; width: number; height: number }; // Uusi muoto lisätty!

            

              
                Copy
              
            
          

`getArea`-funktio on nyt epätäydellinen. Jos se saa `rectangle`, `switch`-lauseella ei ole vastaavaa tapausta, funktio suoritetaan loppuun ja JavaScript/TypeScriptissä se palauttaa `undefined`. Kutsuva koodi odotti `number`, mutta saa `undefined`, mikä johtaa `NaN`-virheeseen tai muihin hienovaraisiin virheisiin kaukana alavirtaan. Kääntäjä ei antanut meille varoitusta.

Ratkaisu: `never`-tyyppi suojana

Voimme korjata tämän käyttämällä `never`-tyyppiä `switch`-lauseen `default`-tapauksessa. Tämä yksinkertainen lisäys muuttaa kääntäjän valppaaksi kumppaniksemme.

            function getAreaWithExhaustiveCheck(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      return Math.PI * shape.radius ** 2;

    case 'square':
      return shape.sideLength ** 2;

    // Entä 'rectangle'? Unohdimme sen.

    default:
      // Tässä tapahtuu taika.
      const _exhaustiveCheck: never = shape;
      // Yllä oleva rivi aiheuttaa nyt käännösaikaisen virheen!
      // Tyyppi 'Rectangle' ei ole määritettävissä tyypiksi 'never'.
      return _exhaustiveCheck;
  }
}
            

              
                Copy
              
            
          

Puretaan miksi tämä toimii:

1. Tyypin kaventaminen: Jokaisen `case`-lohkon sisällä TypeScriptin kääntäjä on tarpeeksi älykäs kaventamaan `shape`-muuttujan tyypin. Kohdassa `case 'circle'`, kääntäjä tietää, että `shape` on `{ kind: 'circle'; radius: number }`.
2. `default`-lohko: Kun koodi saavuttaa `default`-lohkon, kääntäjä päättelee, mitä tyyppejä `shape` voi mahdollisesti olla. Se vähentää kaikki käsitellyt tapaukset alkuperäisestä `Shape`-unionista.
3. Virhetilanne: Päivitetyssä esimerkissä käsittelimme `'circle'` ja `'square'`. Siksi `default`-lohkon sisällä kääntäjä tietää, että `shape` on oltava `{ kind: 'rectangle'; ... }`. Koodimme yrittää sitten määrittää tämän `rectangle`-objektin `_exhaustiveCheck`-muuttujalle, jonka tyyppi on `never`. Tämä määritys epäonnistuu selkeällä tyyppivirheellä: `Tyyppi 'Rectangle' ei ole määritettävissä tyypiksi 'never'`. Virhe havaitaan ennen kuin koodia edes suoritetaan!
4. Onnistumistilanne: Jos lisäämme `'rectangle'`-tapauksen, niin `default`-lohkossa kääntäjä on käyttänyt kaikki mahdollisuudet. `shape`-tyyppi kavennetaan `never`-tyypiksi (se ei voi olla ympyrä, neliö tai suorakulmio, joten se on mahdoton tyyppi). Tyypin `never` arvon määrittäminen tyypin `never` muuttujalle on täysin pätevää. Koodi kääntyy ilman virheitä.

Tämä malli, jota usein kutsutaan "tyhjentävyystempuksi", käytännössä valtuuttaa kääntäjän varmistamaan täydellisyyden. Se muuttaa hauraan suoritusaikaisen käytännön vankaksi käännösaikaiseksi takuuksi.

Tyhjentävä tarkistus vs. perinteinen virheidenhallinta

On houkuttelevaa ajatella tyhjentävää tarkistusta virheidenhallinnan korvaajana, mutta se on väärinkäsitys. Ne ovat toisiaan täydentäviä työkaluja, jotka on suunniteltu ratkaisemaan erilaisia ongelmaluokkia. Keskeinen ero on siinä, mitä ne on suunniteltu käsittelemään: ennustettavia, tunnettuja tiloja verrattuna ennalta arvaamattomiin, poikkeuksellisiin tapahtumiin.

Käsitteiden määrittely

• Virheidenhallinta on suoritusaikainen strategia sellaisten poikkeuksellisten ja ennalta arvaamattomien tilanteiden hallintaan, jotka ovat usein ohjelman hallinnan ulkopuolella. Se käsittelee epäonnistumisia, joita voi ja tapahtuu suorituksen aikana.
  • Esimerkkejä: Verkkopyynnön epäonnistuminen, tiedoston löytämättömyys levyltä, virheellinen käyttäjän syöte, tietokantayhteyden aikakatkaisu.
  • Työkalut: `try...catch`-lohkot, `Promise.reject()`, virhekoodien tai `null`:n palauttaminen, `Result`-tyypit (kuten Rust-kielissä).
• Tyhjentävä tarkistus on käännösaikainen strategia sen varmistamiseksi, että kaikki tunnetut, kelvolliset loogiset polut tai datan tilat käsitellään nimenomaisesti ohjelman logiikassa. Kyse on sen varmistamisesta, että koodisi on täydellinen.
  • Esimerkkejä: Enumin kaikkien varianttien käsittely, erotetun unionin kaikkien tyyppien käsittely, äärellisen tilakoneen kaikkien tilojen hallinta.
  • Työkalut: `never`-tyyppi, kielen pakottama `switch`- tai `match`-tyhjentävyys (kuten Swiftissä ja Rustissa).

Ohjaava periaate: Tunnetut vs. tuntemattomat

Yksinkertainen tapa päättää, mitä lähestymistapaa käytetään, on kysyä itseltäsi ongelman luonteesta:

• Onko tämä joukko mahdollisuuksia, jotka olen määritellyt ja joita hallitsen koodipohjassani? Käytä tyhjentävää tarkistusta. Nämä ovat "tunnettuja". `Shape`-unionisi on täydellinen esimerkki; määrittelet kaikki mahdolliset muodot.
• Onko tämä tapahtuma, joka on peräisin ulkoisesta järjestelmästä, käyttäjältä tai ympäristöstä, jossa epäonnistuminen on mahdollista ja tarkka syöte on arvaamaton? Käytä virheidenhallintaa. Nämä ovat "tuntemattomia". Et voi käyttää tyyppijärjestelmää todistaaksesi, että verkko on aina käytettävissä.

Skenaarioanalyysi: Milloin käyttää mitä

Skenaario 1: API-vastauksen jäsentäminen (virheidenhallinta)

Oletetaan, että haet käyttäjätietoja kolmannen osapuolen API:sta. API-dokumentaatio sanoo, että se palauttaa JSON-objektin, jossa on `status`-kenttä. Et voi luottaa tähän käännösaikaisesti. Verkko voi olla alhaalla, API voidaan poistaa käytöstä ja palauttaa 500-virhe tai se voi palauttaa virheellisen JSON-merkkijonon. Tämä on virheidenhallinnan aluetta.

            async function fetchUser(userId: string): Promise<User> {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) {
      // Käsittele HTTP-virheitä (esim. 404, 500)
      throw new Error(`API-virhe: ${response.status}`);
    }
    const data = await response.json();
    // Tässä lisäät myös datarakenteen suoritusaikaisen validoinnin
    return data as User;
  } catch (error) {
    // Käsittele verkkovirheitä, JSON-jäsentämisvirheitä jne.
    console.error("Käyttäjän nouto epäonnistui:", error);
    throw error; // Heitä uudelleen tai käsittele hienovaraisesti
  }
}
            

              
                Copy
              
            
          

`never`-tyypin käyttäminen tässä olisi sopimatonta, koska epäonnistumisen mahdollisuudet ovat rajattomat ja tyyppijärjestelmämme ulkopuolella.

Skenaario 2: UI-komponentin tilan renderöinti (tyhjentävä tarkistus)

Oletetaan nyt, että UI-komponenttisi voi olla jossakin useista hyvin määritellyistä tiloista. Hallitset näitä tiloja kokonaan sovelluskoodissasi. Tämä on täydellinen ehdokas erotetulle unionille ja tyhjentävälle tarkistukselle.

            type ComponentState =
  | { status: 'loading' }
  | { status: 'success'; data: string[] }
  | { status: 'error'; message: string };

function renderComponent(state: ComponentState): string { // Palauttaa HTML-merkkijonon
  switch (state.status) {
    case 'loading':
      return `<div>Ladataan...</div>`;
    case 'success':
      return `<ul>${state.data.map(item => `<li>${item}</li>`).join('')}</ul>`;
    case 'error':
      return `<div class="error">Virhe: ${state.message}</div>`;
    default:
      // Jos myöhemmin lisäämme 'submitting'-tilan, tämä rivi suojaa meitä!
      const _exhaustiveCheck: never = state;
      throw new Error(`Käsittelemätön tila: ${_exhaustiveCheck}`);
  }
}
            

              
                Copy
              
            
          

Jos kehittäjä lisää uuden tilan, `{ status: 'idle' }`, kääntäjä merkitsee `renderComponent`-funktion välittömästi epätäydelliseksi estäen UI-virheen, jossa komponentti renderöityy tyhjänä tilana.

Synergia: Molempien lähestymistapojen yhdistäminen vankkoihin järjestelmiin

Joustavimmat järjestelmät eivät valitse toista toisen sijasta; ne käyttävät molempia yhdessä. Virheidenhallinta hallitsee kaoottista ulkomaailmaa, kun taas tyhjentävä tarkistus varmistaa, että sisäinen logiikka on terve ja täydellinen. Virheidenhallintarajapinnan tulos muuttuu usein tyhjentävään tarkistukseen luottavan järjestelmän syötteeksi.

Tarkennetaan API:n noutoesimerkkiämme. Funktio voi käsitellä arvaamattomia verkkovirheitä, mutta kun se onnistuu tai epäonnistuu hallitulla tavalla, se palauttaa ennustettavan, hyvin tyypitetyn tuloksen, jonka sovelluksemme muu osa voi käsitellä luottavaisin mielin.

            // 1. Määrittele ennustettava, hyvin tyypitetty tulos sisäiselle logiikallemme.
type FetchResult<T> =
  | { status: 'success'; data: T }
  | { status: 'error'; error: Error };

// 2. Funktio käyttää nyt virheidenhallintaa tuottaakseen tuloksen, joka voidaan tarkistaa tyhjentävästi.
async function fetchUserData(userId: string): Promise<FetchResult<User>> {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) {
      throw new Error(`API palautti tilan ${response.status}`);
    }
    const data = await response.json();
    // Lisää suoritusaikainen validointi tähän (esim. Zodilla tai io-ts:llä)
    return { status: 'success', data: data as User };
  } catch (error) {
    // Otamme kiinni KAIKKI mahdolliset virheet ja käärimme ne tunnettuun rakenteeseemme.
    return { status: 'error', error: error instanceof Error ? error : new Error('Tapahtui tuntematon virhe') };
  }
}

// 3. Kutsuva koodi voi nyt käyttää tyhjentävää tarkistusta puhtaaseen ja turvalliseen logiikkaan.
async function displayUser(userId: string) {
  const result = await fetchUserData(userId);

  switch (result.status) {
    case 'success':
      console.log(`Käyttäjän nimi: ${result.data.name}`);
      break;
    case 'error':
      console.error(`Käyttäjän näyttäminen epäonnistui: ${result.error.message}`);
      break;
    default:
      const _exhaustiveCheck: never = result;
      // Tämä varmistaa, että jos lisäämme 'loading'-tilan FetchResultiin,
      // tämä koodilohko epäonnistuu, kunnes käsittelemme sen.
      return _exhaustiveCheck;
  }
}
            

              
                Copy
              
            
          

Tämä yhdistetty malli on uskomattoman tehokas. `fetchUserData`-funktio toimii rajapintana ja muuntaa verkko pyyntöjen arvaamattoman maailman ennustettavaksi, erotetuksi unioniksi. Sovelluksen muu osa voi sitten toimia tällä puhtaalla datarakenteella käännösaikaisten tyhjentävyystarkistusten täydellä turvaverkolla.

Globaali näkökulma: `never` muissa kielissä

Pohjatyypin ja käännösaikaisen tyhjentävyyden käsite ei ole ainutlaatuinen TypeScriptille. Se on tunnusmerkki monille moderneille, turvallisuuteen keskittyville kielille. Sen toteutuksen näkeminen muualla vahvistaa sen perustavanlaatuisen tärkeyden ohjelmistotuotannossa.

• Rust: Rustilla on `!` -tyyppi, jota kutsutaan "never type". Se on sellaisten funktioiden palautustyyppi, jotka "divergoituvat", kuten `panic!()`-makro, joka lopettaa nykyisen suoritusketjun. Rustin tehokas `match`-lauseke (sen versio `switch`-lausekkeesta) varmistaa tyhjentävyyden oletuksena. Jos `match` on `enum` ja et onnistu kattamaan kaikkia variantteja, koodi ei käänny. Et tarvitse manuaalista `never`-temppua, koska kieli tarjoaa tämän turvallisuuden valmiiksi.
• Swift: Swiftillä on tyhjä enum nimeltä `Never`. Sitä käytetään osoittamaan, että funktio tai metodi ei koskaan palaa, joko heittämällä virheen tai olemalla lopettamatta. Kuten Rustissa, Swiftin `switch`-lausekkeiden on oltava tyhjentäviä oletuksena, mikä tarjoaa käännösaikaisen turvallisuuden työskennellessä enumin kanssa.
• Kotlin: Kotlinilla on `Nothing`-tyyppi, joka on sen tyyppijärjestelmän pohjatyyppi. Sitä käytetään osoittamaan, että funktio ei koskaan palaa, kuten standardikirjaston `TODO()`-funktio, joka heittää aina virheen. Kotlinin `when`-lauseketta (sen `switch`-vastinetta) voidaan käyttää myös tyhjentäviin tarkistuksiin, ja kääntäjä antaa varoituksen tai virheen, jos se ei ole tyhjentävä, kun sitä käytetään lausekkeena.
• Python (tyyppivihjeillä): Pythonin `typing`-moduuli sisältää `NoReturn`, jota voidaan käyttää sellaisten funktioiden merkitsemiseen, jotka eivät koskaan palaa. Vaikka Pythonin tyyppijärjestelmä on asteittainen eikä yhtä tiukka kuin Rustin tai Swiftin, nämä annotaatiot tarjoavat arvokasta tietoa staattisille analyysityökaluille, kuten Mypy, jotka voivat sitten suorittaa perusteellisempia tarkistuksia.

Yhteinen säie näissä monimuotoisissa ekosysteemeissä on sen tunnustaminen, että mahdottomien tilojen tekeminen ei-edustettavaksi tyyppitasolla on tehokas tapa poistaa kokonaisia virheluokkia.

Toimivia oivalluksia ja parhaita käytäntöjä

Integroiaksesi tämän tehokkaan konseptin päivittäiseen työhösi, harkitse seuraavia käytäntöjä:

1. Hyväksy erotetut unionit: Mallinna data aktiivisesti erotetuilla unioneilla (joita kutsutaan myös merkityiksi unioneiksi tai summatyypeiksi) aina, kun sinulla on tyyppi, joka voi olla yksi useista erillisistä varianteista. Tämä on perusta, jolle tyhjentävä tarkistus on rakennettu. Mallinna API-tuloksia, komponentin tiloja ja tapahtumia tällä tavalla.
2. Tee laittomista tiloista ei-edustettavia: Tämä on tyyppivetoisen suunnittelun ydinkohta. Jos käyttäjä ei voi olla samaan aikaan ylläpitäjä ja vieras, tyyppijärjestelmäsi tulisi heijastaa sitä. Käytä unioneita (`A | B`) useiden valinnaisten boolean-lippujen (`isAdmin?: boolean; isGuest?: boolean;`) sijaan. `never`-tyyppi on paras työkalu sen todistamiseen, että tila on ei-edustettava.
3. Luo uudelleenkäytettävä aputoiminto: `default`-tapauksen voidaan tehdä puhtaammaksi yksinkertaisella aputoiminnolla. Tämä tarjoaa myös kuvaavamman virheen, jos koodi koskaan saavutetaan suoritusaikana (jonka pitäisi olla mahdotonta).

               function assertNever(value: never): never {
     throw new Error(`Käsittelemätön erotetun unionin jäsen: ${JSON.stringify(value)}`);
   }
   
   // Käyttö:
   default:
     assertNever(shape); // Puhdistaja ja tarjoaa paremman suoritusaikaisen virheilmoituksen.
               
   
                 
                   Copy
                 
               
             

4. Kuuntele kääntäjääsi: Älä pidä tyhjentävyysvirhettä haittana, vaan lahjana. Kääntäjä toimii ahkerana, automatisoituna kooditarkastajana, joka on löytänyt loogisen puutteen ohjelmastasi. Kiitä sitä ja korjaa koodi.

Johtopäätös: Koodipohjasi äänetön suojelija

`never`-tyyppi on paljon enemmän kuin teoreettinen uteliaisuus; se on pragmaattinen ja tehokas työkalu vankan, itse dokumentoivan ja ylläpidettävän ohjelmiston rakentamiseen. Hyödyntämällä sitä tyhjentävään tarkistukseen, muutamme pohjimmiltaan tapaamme lähestyä oikeellisuutta. Siirrämme taakan loogisen täydellisyyden varmistamisesta erehtyväisestä ihmismuistista ja suoritusaikaisesta testauksesta käännösaikaisen tyyppianalyysin erehtymättömään, automatisoituun maailmaan.

Vaikka perinteinen virheidenhallinta on edelleen olennaista ulkoisten järjestelmien arvaamattoman luonteen hallinnassa, tyhjentävä tarkistus tarjoaa täydentävän takuun sovelluksiemme sisäiselle, tunnetulle logiikalle. Yhdessä ne muodostavat monikerroksisen suojan virheitä vastaan luoden järjestelmiä, jotka eivät ole vain vähemmän alttiita epäonnistumisille, vaan myös helpompia perustella ja turvallisempia refaktoroida.

Seuraavan kerran, kun kirjoitat `switch`-lausetta tai pitkää `if-else-if`-ketjua tunnettujen mahdollisuuksien joukossa, pysähdy ja kysy: voiko `never`-tyyppi toimia tämän koodin äänettömänä suojelijana? Tekemällä niin kirjoitat koodia, joka ei ole vain oikein tänään, vaan on myös suojattu huomisilta unohduksilta.