Здравствуйте, Sharov, Вы писали:

S>В нашем деле просто изучить, почитать гадлайны и оф. документацию не помогает. Learning by doing(c). Времени на это не всегда хватает.
Learning by doing не работает с проектированием. Нужен склад мышления отличный и от менеджерского и от девелоперского. Не, личное кладбище проектов здорово вправляет мозги, но выходит дороговато


S>>Неправильно вопрос ставишь. Ситуация "я собираюсь использовать фичу не по назначению и оправдываю это жизненной необходимостью" — это всегда (без исключений) следствие XY problem aka проблема мангустов в почтовом ящике

Автор: Sinix
Дата: 01.06.14

.
S>Откройте для себя нестандартные решения, подход к задачам.
"я собираюсь использовать фичу не по назначению" и "нестандартные решения" — несколько разные вещи

В нашей ситуации нестандартное решение не нужно вообще. Смотрим:

Выше уже написали -- как протаскивать ошибку? Если обработчик на 10 уровней сверху.

Проблема тут явно не в самой обработке, а уровнем выше, в дубовой архитектуре, которая течёт абстракциями на десять уровней вверх. Серьёзно, у тебя цепочка из 10 нетривиальных методов и все они спроектированы с учётом неявного контракта "если не распарсил проблему, тут может быть вот такое вот исключение"? Ну изврат же, проще задокументировать контракт через "SomeResult<T>", чем объяснять каждому девелоперу в команде про "вот этот метод только через try-catch вызывать"

S>В первую очередь Вы инженер,а уже потом программист.
Где-то тут должны быть семь взаимно перпендикулярных линий, одна в форме котёнка Не, из принципа извратиться и не так можно, главное забить на то, что топикстартер ищет решение для продакшна.


S>Дураки какиета. Не чтобы взять и изучить матчасть и документацию, косяки явы и т.п. Взяли и запили на основе сущ. механизма. И оставили все как есть.
Изучили, внезапно. Результат — в реализации и гадлайнах. Ссылки уже давал, если есть _конкретный_ сценарий, где нужно городить control flow именно на исключениях — не вопрос, с интересом посмотрю.

Здравствуйте, Sharov, Вы писали:

S>В нашем деле просто изучить, почитать гадлайны и оф. документацию не помогает. Learning by doing(c). Времени на это не всегда хватает.
Learning by doing не работает с проектированием. Нужен склад мышления отличный и от менеджерского и от девелоперского. Не, личное кладбище проектов здорово вправляет мозги, но выходит дороговато


S>>Неправильно вопрос ставишь. Ситуация "я собираюсь использовать фичу не по назначению и оправдываю это жизненной необходимостью" — это всегда (без исключений) следствие XY problem aka проблема мангустов в почтовом ящике

Автор: Sinix
Дата: 01.06.14

.
S>Откройте для себя нестандартные решения, подход к задачам.
"я собираюсь использовать фичу не по назначению" и "нестандартные решения" — несколько разные вещи

В нашей ситуации нестандартное решение не нужно вообще. Смотрим:

Выше уже написали -- как протаскивать ошибку? Если обработчик на 10 уровней сверху.

Проблема тут явно не в самой обработке, а уровнем выше, в дубовой архитектуре, которая течёт абстракциями на десять уровней вверх. Серьёзно, у тебя цепочка из 10 нетривиальных методов и все они спроектированы с учётом неявного контракта "если не распарсил проблему, тут может быть вот такое вот исключение"? Ну изврат же, проще задокументировать контракт через "SomeResult<T>", чем объяснять каждому девелоперу в команде про "вот этот метод только через try-catch вызывать"

S>В первую очередь Вы инженер,а уже потом программист.
Где-то тут должны быть семь взаимно перпендикулярных линий, одна в форме котёнка Не, из принципа извратиться и не так можно, главное забить на то, что топикстартер ищет решение для продакшна.


S>Дураки какиета. Не чтобы взять и изучить матчасть и документацию, косяки явы и т.п. Взяли и запили на основе сущ. механизма. И оставили все как есть.
Изучили, внезапно (вторая ссылка закрывает вопрос полностью). Результат — в реализации и гадлайнах. Ссылки уже давал, если есть _конкретный_ сценарий, где нужно городить control flow именно на исключениях — не вопрос, с интересом посмотрю.