тебе не придется смотреть стектрейс, если будешь делать библиотеки без ошибок ;)

Так не бывает

тебе не придется смотреть стектрейс, если будешь делать библиотеки без ошибок ;)

Да и к тому же, или если я допустил ошибку в работе с библиотекой, то хотелось бы знать что и почему

Если я хочу отладить, куда мне точку останова воткнуть

Ну тут source maps, как бы

А для того, чтобы было понятно, что происходит, нужно делать качественные сообщения об ошибках

И это кстати такая боль, что ппц ?

Ну тут source maps, как бы

Не везде они работают

Реально от состояния "production ready" до "ага, понятно в чём дело" просто бездна труда

Так надо просто делать minimal API surface. Меньше сущностей - меньше вероятность проблем, причем зависимость экспоненциальная

Я только сейчас понимаю, какое гигантское количество времени вкладывают в это создатели либ типа реакта

И дробить на микромодули внутри

Так надо просто делать minimal API surface. Меньше сущностей - меньше вероятность проблем, причем зависимость экспоненциальная

Легко сказать

Так надо просто делать minimal API surface. Меньше сущностей - меньше вероятность проблем, причем зависимость экспоненциальная

Удачи

Знаю, сам четвертый месяц внутреннее апи делаю

Так надо просто делать minimal API surface. Меньше сущностей - меньше вероятность проблем, причем зависимость экспоненциальная

Это если у твоего модуля в принципе есть минимизируемое состояние

Раскрой мысль, пожалуйста

Так надо просто делать minimal API surface. Меньше сущностей - меньше вероятность проблем, причем зависимость экспоненциальная

Далеко не все модули могут впринципе имеет минимальное API Чаще люди выбирают тот модуль, у которого API богаче (помимо других характеристик)

Если у комбинации "состояние приложения x реакция сервера" дерево конечных исходов больше сибирской тайги, то тут как не минимизируй

Ну так нужно тренироваться впихивать функционал в меньшее количество сущностей)

У тебя например многоступенчатый процесс, каждый шаг которого может упасть самым разнообразным уникальным способом чисто by design

Тупо например потому что ты в этих шагах делаешь кардинально разные операции

Я сейчас делаю аналог одной очень популярной c++/Python либы (уровень бабеля по популярности), апи начал брать под кальку. Либа очень сложная. Уменьшил количество сущностей на треть и прям дышать стало легче)

А почему в таком случае не акторную модель использовать?

Детали реализации тут не помогут особо

Если честно - пока не убедил, что твой монолит не дробится. Но холивар я сейчас морально не готов устраивать)

В случае одной ошибки можно повторить процесс, в случае другой попробовать иным способом, третья — бесповоротный терминальный конец, о четвертой нужно просто уведомить пользователя, потому что это не критично но полезно

Список можно продолжать

Можно работать с ним эффективно и изящно, но сам груз дерева возможных исходов это не снижает

ERROR: S client not available

Пока что не вижу ничего за рамками продвинутого логгера и стейтмашины или акторов)

Мне кажется, что ты с чего то посчитал, что здесь есть какая-то принципиальная проблема

Единственная проблема — это конечность человеческой жизни

А когда тебе надо задокументировать и отработать кучу вариантов, то это нудно и долго даже просто когда ты записываешь текст конечных сообщений столбиком в блокнот

Без акторов и вжух-машин

Используйте популярные решения

React?

У меня кажется переизбыток сарказма сегодня

Я не знаю, вы тут Джависты)

шта?

Всем привет!

Нет

Кто может помочь с chrome extensions ?