Я создал некоторую абстракцию для базы, которая может вызывать что угодно, главное чтобы сохранялся контракт.
Выглядит примерно так: interface UserRepo { createOne(input): User; }
В данном случае абстракция вызывает Prisma и Zod, которые в свою очередь могут генерировать ошибки разных типов.
- Которые я хочу обернуть в некоторый interface UserRepoError extends Error {};
Задача донести причину ошибки до вызывающей стороны систематизированным, максимально доступным образом.
- Если привязаться к ошибкам этих пакетов - всё довольно просто, т.к. уже реализовано. Однако как их обернуть самому я не представляю - потому что ранее подобным не занимался.
Единственное что мне пришло в голову, это пронумеровать все ошибки и работать с этими псевдо-кодами.
Проблема идеологическая.
Как себя будет вести и что показывать пользователю итоговое приложение, использующее вашу библиотеку?
Какой тип ошибок у вызываемых методов тут может быть? На сколько вы хотите скрыть от пользователя библиотеки эту информацию? Вы готовы полностью переписать все типы ошибок той же призмы на свои, а из-за лени сделаете их менее информативными? агрегировав в более общие? В чем проблема просто передать ошибку как есть дальше?
Написано
historydev
@historydev Автор вопроса, куратор тега JavaScript
Эти ошибки могут вернуть любые пакеты или даже голый sql и ручная проверка, я хочу привести это к фиксированному формату, чтобы в случае замены этих пакетов нужно было лишь проецировать новые ошибки на свой формат.
Переписать все типы ошибок это как раз моё решение с нумерацией, но сроки уже на пороге, а работы меньше не становится.
Если я передам её дальше, в случае замены пакета вызывающая сторона получает в багаж ломающее изменение, а так-же получает информацию о внутреннем устройстве модуля - моя цель избежать этого.
historydev, а так задача сделать поддержку разных пакетов?
тогда никаких вариантов кроме своей системы ошибок у тебя нет.
p.s. настоятельно рекомендую не скрывать оригинальное сообщение об ошибке, пусть оно где то как то будет доступно
Написано
historydev
@historydev Автор вопроса, куратор тега JavaScript
rPman, Вот именно! А как эту систему ошибок строить - я не понимаю. Могу малой кровью конвертировать любые пакетные ошибки в свои, но как идентифицировать их для вызывающей стороны - непонятно.
- Подумываю взять фиксированный набор ошибок которые с большей вероятностью могут возникнуть у вызывающей стороны, а остальные отнести к непредвиденным и по необходимости расширять, например валидацию проксирую, а подключение к базе нет.
открываешь табличный процессор (excel/libre calc/google spreadsheet/..) открываешь в соседнем окне документацию по используемой библиотеке/фреймворке/базе данных (или исходники, если документация как обычно не полна), и собираешь строчка за строчкой все виды ошибок в первой колонке... пытаясь объединить однотипные ошибки (например not found везде имеет один смысл, или connection error/file not found для того же sqlite)... медитируешь над этой табличкой, возможно у тебя уже есть опыт работы с этими библиотеками, которые ты хочешь проксировать, наверняка есть что то, что не имеет никакого смысла обрабатывать отдельно.. и постарайся не объединять в одну ошибку что то типа не могу обновить потому что 'мешает уникальный индекс' и 'место на диске кончилось', потому как пользователь выше может ловить исключение неуникальности индекса как часть рабочего процесса, а вот место на диске нужно ловить как фатальная,..
Написано
historydev
@historydev Автор вопроса, куратор тега JavaScript
открываешь табличный процессор (excel/libre calc/google spreadsheet/..) открываешь в соседнем окне документацию по используемой библиотеке/фреймворке/базе данных (или исходники, если документация как обычно не полна), и собираешь строчка за строчкой все виды ошибок в первой колонке... пытаясь объединить однотипные ошибки (например not found везде имеет один смысл, или connection error/file not found для того же sqlite)...
- Это самая очевидная часть.
Вот пример проблемы: Если я передам сообщение без конкретной информации, например "user not found", в таком случае для локализации этой ошибки мне придётся работать с этим текстом, а наличие некоторого кода X и доп. информации даст возможность понимать что произошло не вникая в сообщение.
- Чтобы вызывающая сторона могла утверждать: Если err.code.X === "U1" показать "Пользователь не найден". Вместо вывода err.message
эмм, вообще то обычно высокоуровневые языки подразумевают использование исключений, класс которого сообщает об ошибке, а вот текстовая информация - это сопроводиловка для пользователя приложения, если нижестоящая библиотека не предоставляет кода, то выявлять тип ошибки придется по тексту.
если же у тебя нет системы исключений, то тип ошибки кодируй кодом, но понятно что этот код не обязательно будет совпадать с кодом ошибки нижестоящей библиотеки, так как у тебя будет использоваться разные типы и их коды могут не совпадать или наоборот совпадать численно но не по смыслу.
вот это соответствие текст сообщения об ошибке/какая то логика, например регулярка/код ошибки в нижестоящей библиотеке -> код ошибки в твоем приложении и нужно составить в табличке
Написано
historydev
@historydev Автор вопроса, куратор тега JavaScript
rPman, Понял, значит попроще не получится.. Спасибо.
это классическая задача сведения двух и более классификаторов, когда значения одного ставятся в соответствие другому.
пару раз я экспериментировал и решал задачу с помощью ИИ, первый раз во времена первой llama 70b, получилось не очень но собранная им информация использовалась как основа, ее правил выверял и т.п.... недавно ставил эксперимент в другой задаче (записей было несколько сотен, очень не хотелось вручную этим заниматься), помню phi4 и гугловская открытая справились неплохо, ну а топовые онлайн и подавно прекрасно решали (а вот открытая от яндекса нифига не справилась)
но в тех задачах малое количество значений сравнивались по одному из большого количества... если же нужно сравнивать многие ко многим, начнутся проблемы, ибо контекстное окно не резиновое и как только количество информации превышает десятки, даже умные ИИ начинают это пропускать, т.е. нужно будет поверх этого наворачивать умную систему агентов и/или rag.. в общем проявить креативность (например разделить один из справочников на части по 10-20 записей и прогонять их каждую со всеми записями из другого справочника, затем собранные данные статистически объединить)
Написано
historydev
@historydev Автор вопроса, куратор тега JavaScript
rPman, Идея хорошая, но столько времени в данный момент у меня нет, покрою минимальное кол-во ошибок, а как появится время вернусь к этому сценарию.
Проще взять за основу одну из систем, где больше всего уже предусмотрено и тупо дополнить и\или смапить в оную все остальные ошибки. Так будет меньше телодвижений, главное чтоб авторы системы не решили когда-нить её целиком перелопатить.:)
