Ого наплодили.

grasoff.netchabapok,

а если выбросить, например, ejbexception, вместо mywrappedioexception, это приемлемо? что скажешь/посоветуешь? спасибо!!
...
мне разъясните, пожалуйста!! работа стоит!!


Думать своей головой и находить в сети материал (это к "работа стоит").

Скромно так посоветую придерживаться того стиля, которого требует используемый вами фреймворк. Если там написано что-то типа "если хотите рюшечки, оберните в ejbexception", и в этом состоит его Великая Идея, то можете оборачивать.

Я лишь против маниакального оборачивания, без особых на то оснований, т.к. это говнокод. То что иногда приходится обернуть Exception в своего наследника RuntimeException - это как раз одно из оснований. Собственно, там другого выхода просто нет - надо доделывать свой код под существующий (возможно говно)код, поэтому моя реплика не касается этого случая.

Возьмем например JSONTokener.java из json.org. Есть там такой метод next() throws JSONException, есть там такой фрагмент:



Это при том, что JSONException у них checked. Налицо врапперовка головного мозга, или автор банально не умеет пользоваться экзепшенами. Либа парадоксально распространенная, давайте посмотрим к чему эта врапперовка приводит.

Предположим, IOException не было бы обернуто. Тогда все просто -- на том уровне, где мы можем сделать реконнект потока, мы бы ловили IOException и делали бы ему реконнект. На том уровне, где мы бы знали что делать с хреновым json-ом мы бы ловили JSONException, т.к. я понимаю его именно как ошибку парсинга.

А что получается по факту? Там где, вызывается парсинг, надо что-то знать о вводе-выводе, проверять "а не io ли у него внутри" и если io, отдавать наверх. То есть, дополнительно, в каждом месте, добавлять десяток строк кода. В результате у нас мухи от котлет отдельно уже не будут.

Или же (в зависимости от того, что у нас куда вложено), там, где у нас чтение, ВНЕЗАПНО приходится знать еще и JSONException, потому что это может оказаться на самом деле io. При этом если у нас, например, кроме json-а добавится хреновая имплементация bsjon в том же говноситле - со своим BSONException, то нам понадобится менять код нашего читателя, добавляя в него перехват еще и BSONException с проверкой а не io ли у него внутри. В особо запущенных случаях, у него внутри может оказаться не io, но снова ABCException, внутри которого BLALALAException, внутри которого уже io. Кто не верит что так бывает - недостаточно фрилансил, работая с чужим кодом. Тут уже без рекурсивного парсера, через рефлексию вытягивающего заврапленное IOException на любом уровне, не обойтись. Но вот беда - такой парсер тоже может бросать исключения...

Ну или можно поправить код в либе. Это уже кому как. :))


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