Впровадження класифікації помилок

Цей перелік відстежує впровадження єдиної семантики обробки помилок у основних компонентах і плагінах середовища виконання.

Канонічні коди

include/pipeline/ErrorCodes.h є джерелом істини. У каталог кодів помилок має бути задокументовано кожну константу C++, кожне ім’я Python ERROR_* та процес переходу від загальних кодів до більш конкретних.

Частини коду, що виконуються.

1. Створення структури таксономії.
2. Створення/перевірка коду.
3. Завантаження коду під час виконання (у середовищі виконання).
4. Парсер/відкритий код для введення/виведення даних графа.
5. Тести + документація

Перевірка сумісності.

• Розглядайте зміну точного коду, який повертається існуючою функцією у разі виникнення помилки, як зміну поведінки, що призводить до несумісності. змінюйте, навіть якщо не змінюються сигнатури C++ або Python.
• Задокументуйте відповідності між старими та новими значеннями в загальнодоступній таблиці міграції.
• Зберігайте резервні коди (build.parse_launch, runtime.pull, і runtime.element_failed) лише для випадків, коли неможливо визначити конкретну класифікацію помилки.
• Перевірте версіоновані ключі simaai-neat-error для з’єднань у виробничих збірках і проаналізуйте реальні дані. GstMessage через Core.

Перелік пунктів для перевірки.

• NeatError.report().error_code не може бути порожнім у разі виникнення збоїв у термінальному фреймворку.
• PullError.code заповнюється під час виникнення помилок під час отримання даних у середовищі виконання.
• Помилки обгортки графа містять код + контекст + підказку (без загального тексту-заміни).
• Помилки під час розбору JSON включають offset= та near='...'.
• Негативні тести підтверджують наявність коду та стабільних фрагментів повідомлень для кожного класу таксономії.
• Документація з діагностики та документація з архітектури містить схему сортування: перегляньте error_code. перевірте repro_note, перевірте діагностику шини, а потім повторіть з repro_gst_launch.