DanLevy.net

Quiz:Fortgeschrittene JS‑Fehlerbeherrschung

Sind Ihre Ausnahmen wirklich außergewöhnlich?

Glaubst du, du kennst JavaScript‑Fehler in- und auswendig?

1. 

Serialisierungsüberraschungen

Was gibt JSON.stringify(error) zurück?

const error = new Error('Oops');
console.log(JSON.stringify(error));

Error-Objekte haben nicht aufzählbare Eigenschaften (message, name, stack), daher gibt JSON.stringify() {} zurück. Das ist ein häufiger Stolperstein beim Senden von Fehlern in API‑Antworten. Verwende JSON.stringify(error, Object.getOwnPropertyNames(error)) oder erstelle stattdessen ein einfaches Objekt.

2. 

Serialisierungsüberraschungen

Was ist der Unterschied zwischen den beiden?

const err = new Error('Test');
console.log(err);
console.log(JSON.stringify(err));

console.log(err) zeigt den Fehler mit seiner Nachricht und dem Stack‑Trace, weil die Konsole eine spezielle Behandlung für Error‑Objekte hat. JSON.stringify(err) liefert '{}', weil Error‑Eigenschaften nicht aufzählbar sind. Dieser Unterschied bringt viele Entwickler beim Debuggen von APIs durcheinander.

3. 

Typprüfungs-Tricks

Was sind die Ergebnisse dieser Prüfungen?

class CustomError extends Error {}
const err = new CustomError('test');


console.log(err instanceof CustomError);
console.log(err instanceof Error);
console.log(err instanceof Object);

Alle drei geben true zurück. CustomError erweitert Error, das wiederum Object erweitert. Der instanceof‑Operator prüft die gesamte Prototypkette, sodass eine CustomError‑Instanz auch eine Instanz von Error und Object ist.

4. 

Typprüfungs-Tricks

Was passiert mit instanceof Error über iframes hinweg?

// In iframe:
const iframeError = new Error('test');
// In parent window:
console.log(iframeError instanceof Error);

instanceof kann über verschiedene Ausführungskontexte (iframes, Workers) false zurückgeben, weil jeder Kontext seinen eigenen Error‑Konstruktor hat. Verwende Object.prototype.toString.call(obj) === '[object Error]' für zuverlässige Fehlererkennung über Kontextgrenzen hinweg.

5. 

Werfen von Nicht-Error-Objekten

Was passiert, wenn du eine Zeichenkette wirfst?

try {
  throw "Oops!";
} catch (e) {
  console.log(e instanceof Error);
  console.log(typeof e);
}

JavaScript erlaubt das Werfen beliebiger Werte. Hier ist e instanceof Error false und typeof e ist "string". Das kann Fehlerbehandlungscode zum Absturz bringen, der annimmt, dass alle gefangenen Ausnahmen Error‑Objekte sind. Wirf immer Error‑Instanzen für bessere Debug‑Informationen.

6. 

Benutzerdefinierte Fehler

Wie lautet der Wert von err.name?

class CustomError extends Error {
  constructor(message) {
    super(message);
    this.name = this.constructor.name;
  }
}
const err = new CustomError('test');
console.log(err.name);

err.name ist "CustomError", weil this.constructor.name den Klassennamen zurückgibt. Das Setzen von this.name = this.constructor.name ist ein gängiges Muster, um sicherzustellen, dass benutzerdefinierte Fehlerklassen den korrekten Namen in Stack‑Traces und Fehlermeldungen anzeigen.

7. 

Benutzerdefinierte Fehler

Was ist die Ausgabe, wenn name nicht gesetzt wird?

class MyError extends Error {
  // No constructor or name setting
}
const err = new MyError('test');
console.log(err.name);

Wenn this.name nicht explizit gesetzt wird, erbt der Fehler die Standard‑name‑Eigenschaft der Error‑Klasse, die "Error" ist. Deshalb sollten benutzerdefinierte Fehlerklassen immer this.name = this.constructor.name im Konstruktor setzen.

8. 

Error-Ursache

Was gibt wrapper.cause.message zurück?

const original = new Error('Original error');
const wrapper = new Error('Wrapper',
  { cause: original }
);
console.log(wrapper.cause.message);

Error.cause (ES2022) ermöglicht das Ketten von Errors, um den ursprünglichen Fehlerkontext zu bewahren. wrapper.cause verweist auf den ursprünglichen Fehler, daher gibt wrapper.cause.message "Original error" zurück. Das ist nützlich, um niedrigere Fehler mit höherem Kontext zu umhüllen.

9. 

Stack-Trace

Was macht Error.captureStackTrace?

function createError(msg) {
  const err = new Error(msg);
  Error.captureStackTrace(err, createError);
  return err;
}
const error = createError('test');

Error.captureStackTrace (V8/Node.js) entfernt die angegebene Funktion (createError) aus dem Stack‑Trace, sodass Fehler‑Factory‑Funktionen für End‑Benutzer unsichtbar werden. Das erzeugt sauberere Stack‑Traces, die auf die Aufrufstelle der Factory zeigen, nicht auf die Factory selbst.

10. 

Nachrichtenvorlagen

Wie lautet die Fehlermeldung?

function validate(value) {
  if (!value) {
    throw new Error(
      `Value ${value} is invalid`
    );
  }
}
try {
  validate(undefined);
} catch (e) {
  console.log(e.message);
}

Template‑Literals wandeln undefined beim Einsetzen in den String "undefined" um. Die Fehlermeldung wird zu "Value undefined is invalid". Für sauberere Meldungen solltest du value ?? 'null' oder ähnliche Prüfungen vor der Interpolation verwenden.

11. 

API-Fallen

Was wird an den Client gesendet?

// Express.js route
app.get('/api/data', (req, res) => {
  const error = new Error('Database failed');
  res.json({ error });
});

res.json() verwendet intern JSON.stringify(), sodass das Error‑Objekt zu {} wird. Der Client erhält {"error":{}}. Um das zu beheben, benutze res.json({ error: error.message }) oder res.json({ error: { message: error.message, name: error.name } }).

12. 

Asynchrone Fehler

Was kann Promise.reject() akzeptieren?

Promise.reject('string').catch(e =>
  console.log(typeof e)
);
Promise.reject({code: 404}).catch(e =>
  console.log(e.code)
);
Promise.reject(42).catch(e =>
  console.log(e)
);

Wie throw akzeptiert Promise.reject() jeden beliebigen Wert – Strings, Objekte, Zahlen usw. Das gibt "string", 404 und 42 aus. Prüfe immer den Typ der abgefangenen Werte in Promise‑Ketten, besonders wenn du mit Drittanbieter‑Code arbeitest, der mit Nicht‑Error‑Werten ablehnen könnte.

13. 

Fehler‑Eigenschaften

Wie zuverlässig sind error.code und error.errno?

const fs = require('fs');
fs.readFile('missing.txt', (err, data) => {
  if (err) {
    console.log(err.code);    // 'ENOENT'
    console.log(err.errno);   // -2
  }
});

Eigenschaften wie code und errno sind umgebungsspezifisch (hier Node.js) und gehören nicht zum standardmäßigen Error‑Objekt. Browser‑Fehler besitzen diese Eigenschaften nicht. Prüfe immer, ob sie existieren: if (err.code === 'ENOENT') anstatt anzunehmen, dass sie vorhanden sind.

14. 

Fehlergrenzen

Was geben diese Prüfungen zurück?

const fakeError = {
  name: 'Error',
  message: 'Fake error',
  stack: 'fake stack'
};


console.log(fakeError instanceof Error);
console.log(Object.prototype.toString.call(
  fakeError
) === '[object Error]');

instanceof Error gibt false zurück, weil das Objekt nicht vom Error‑Konstruktor erstellt wurde. Object.prototype.toString.call() liefert ebenfalls false (es gibt '[object Object]' zurück), weil es den internen [[Class]]‑Slot prüft. Beide Methoden erkennen korrekt, dass es sich um ein gefälschtes Fehlerobjekt handelt.

Beherrsche die Kunst der Fehlerbehandlung

Von Serialisierungs-Fallen bis zu instanceof‑Problemen über Kontextgrenzen – diese fortgeschrittenen Konzepte trennen Junior‑Entwickler von erfahrenen Profis.

Bereit für weitere Herausforderungen? Sieh dir unsere komplette Quiz‑Sammlung für zusätzliche Denksportaufgaben zu JavaScript, Algorithmen und mehr an!

Loading comments...