try/catch - warum wird throw new Error() nicht ausgeführt und ist das die richtige Art, zurückzugeben was genau falsch ist?

[dedlfix]

Tach!

Ich bin ein großer Freund von Minimalismus, deshalb beginne ich mal mit einer rigoros gekürzten Variante deiner createList-Funktion.

function createList(movies) {
  return movies.map(movie => `<li>${escape(movie)}</li>`)
}

Diese Funktion nimmt noch keine Plausibilitätsprüfung der Parameter vor. Spontan fallen mir drei Randfälle ein, über die es sich lohnt genauer nachzudenken:

1. Was ist wenn movies kein Array ist?
2. Was ist wenn ein Element aus movies kein string ist?
3. Was ist wenn das Array movies leer ist?

Wenn man den Minimalismus weiterbetreibt, könnte man auch noch Zusatzfragen stellen.

Zu 1: Ist es denn überhaupt möglich, dass movies kein Array ist? Wer übergibt denn movies? Ist das eine unkontrollierbare Quelle, die alles mögliche liefern kann? Oder ist es höchstens wahrscheinlich, dass es entweder ein Array oder undefined ist? Kann man dem Aufrufer zumuten, ein || [] anzuhängen, um statt undefined ein leeres Array zu liefern? Oder kann das vielleicht in der Funktion stattfinden?

return (movies || []).map(...)

Vielleicht reicht es auch, das undefined so abzufangen, dass kein Fehler geworfen wird, aber auch undefined statt leerem Array als Antwort kommt?

return movies?.map(...)

So kann man auch mit minimalem Aufwand die wahrscheinlichsten Probleme abfangen.

Zu 2: Ist es wahrscheinlich, dass Werte kein String sind?

In einem Template-Literal ist es ja egal, welchen Typ der Wert hat. Notfalls kommt beim automatischen Typecasten zu String 'undefined' oder '[object Object]' raus. Stört (mich) das, wenn jemand Garbage zurückbekommt, wenn Garbage übergeben wird?

Oder wie wäre es mit einem einfachen Typecast?

return movies?.map(movie => doWhatEver(String(movie)));

Ohne Nummer: Wie wahrscheinlich ist es, dass Müll übergeben wird? Vom EVA-Prinzip ausgehend: Steckt diese Funktion im Verarbeitungsteil, sollte man davon ausgehen können, dass der Eingabeteil bereits die gröbsten Probleme erfasst und zurückgewiesen hat. Ansonsten könnte man überlegen, warum das nicht geschehen ist.

Kommen die Daten aus einer Quelle? Warum ist die Fehlererkennung nicht bereits in dem Teil, der die Daten holt?

Generell gesagt: Lohnt sich so eine aufwendige Fehlererkennung überhaupt, oder kann mit Disziplin und Programmstruktur dafür gesorgt werden, dass keine ungültigen Parameter übergeben werden.

Hier auch noch eine dritte Empfehlung für TypeScript. Wenn man sich über die Typen im klaren ist und überall explizite Typeangaben notiert (solange der Typ nicht implizit klar ist), hat man einen Haufen Nachlässigkeitsprobleme gar nicht erst. Zusammen mit einer IDE, die aufgrund der Typinformation, die Typescript erkennt oder auswerten kann, direkt beim Tippen die Probleme erkennt und auch nur gültige Codevervollständigung vorschlägt, ergibt sich ein wertvolles Gespann zur Produktivitätssteigerung.

dedlfix.