Ошибки и битые строки

Реальный лог всегда содержит мусор: обрезанные строки, чужие сообщения, бинарные вставки. Сверло по умолчанию считает это нормой и не останавливает чтение.

Режимы onError#

Значение	Поведение
`'skip'` (по умолчанию)	Строка пропускается, счётчик `parser.stats.skipped` растёт
`'collect'`	Строка пропускается, а `ParseError` кладётся в `parser.errors` (не больше `maxErrors`, по умолчанию 1000)
`'throw'`	Первая же ошибка бросает исключение

const parser = createParser({ format: 'logfmt', onError: 'collect', maxErrors: 50 });

Объект ParseError#

У ошибки есть стабильный code, по которому можно ветвиться, и контекст:

json

{
  "name": "ParseError",
  "code": "E_NO_MATCH",
  "line": 1042,
  "column": 18,
  "raw": "2026-10-01 09:14 ???",
  "message": "line 1042: expected {level:level} at column 18"
}

Код	Когда возникает
`E_NO_MATCH`	Строка не подошла под формат или шаблон
`E_BAD_TS`	Время распознано, но не существует, например 31 ноября
`E_LINE_TOO_LONG`	Строка длиннее `maxLineLength`
`E_QUERY_SYNTAX`	Ошибка в запросе
`E_PATTERN`	Неверный шаблон; бросается при создании разборщика

Не теряйте сырые строки#

Поле raw хранит исходный текст. Для разбора после инцидента удобно писать нераспознанное в отдельный файл:

import { appendFileSync } from 'node:fs';
for (const e of parser.errors) appendFileSync('unparsed.log', e.raw + '\n');

Доля ошибок как сигнал

Если parser.stats.skipped / parser.stats.lines вдруг выросла с нуля до нескольких процентов, чаще всего изменился формат лога после релиза приложения. Это проще заметить по счётчику, чем по пропавшим записям.