Есть, например, клиентский метод в котором мы вызываем апишный метод из другого класса, который кидает исключение(специфическое какоето).
И вот если я хочу по логике кинуть  в клиентском методе то самое исключение в блоке catch, которое кидает апишный метод...
Тоесть так:

Короче говоря, насколько разумный с точки зрения проектирования такой подход? По сути - это делегирование исключния. По дефолту на месте повторного выкидыша исключения в клиенте должно быть всегда чтото другое.. Но вот если мне бы хотелось сохранить и передать то самое исключение так как по логике оно должно отображать суть того самого исключения.
 
P.S. Честно говоря то что я пробую - не совсем относится к пхп, ибо в случае пхп не надо было бы даже писать try-блок: исключение по цепи бы итак передалось. У меня ситуация, где try-блок писать обязательно т.к. IDE матерится и компилятор пошлет к черту.
Вопрос - скорее всего по базовой теории нежели суто по пхп..

Что это? Ява?
 
В пыхе так:

надо кидат тоже самое исключение если тебе надо еще что то сделать, а так ризона нет

Если это Java, то почему бы добавить к сигнатуре метода throws?

upd
хотя throws по-любому понадобится, если только SpecificForObjectXException не наследует RuntimeException
 
и вообще это и на Java не похоже

Исключения можно наследовать:
 

будет напечатано:
строка не найдена
проблема с чтением данных

Timur, да, на джаве.. а не похоже на джаву ибо писал в коде из пхп.. чето протупил сразу джаву выбрать, но тем не менее..
во-вторых(ближе к делу). Твое решение неплохое... но только на 1й взгляд, потому как это не избавляет нас обрамлять вызов objectX.doSomething(); в блок try/catch(потомучто если иде/компилятор знает о том что оно кидается этим исключением, то он ничего и не выполнит).
Отсюда - у нас остается все тот же блок catch в котором надо чтото сделать..

довольно распространенная практика: ловим исключение и бросаем другое, а то, что словили - третьим агрументов в констроуктор ($previous, >= 5.3 only)

Отсюда - у нас остается все тот же блок catch в котором надо чтото сделать..

Да там вообще try/catch не нужен.
Просто допиши throws после списка аргументов и всё - исключение пойдет наверх по стеку вызовов, в поисках первого подходящего catch-блока.
 
http://www.skipy.ru/technics/exceptions.html

Абырвалг

довольно распространенная практика: ловим исключение и бросаем другое, а то, что словили - третьим агрументов в констроуктор ($previous, >= 5.3 only)

Ну можно и так (в Java вторым аргументом), если есть необходимость, например добавить что-то к данному эксцепшену или "сгруппировать" несколько.

Rotten

потомучто если иде/компилятор знает о том что оно кидается этим исключением, то он ничего и не выполнит

Потому что в Java все исключения (кроме RuntimeException, Error и их наследников) являются проверяемыми (checked), т.е. если в методе возможно исключение, то его нужно либо обработать (try/catch), либо явно указать о том, что метод выбрасывает исключение (throws).

Timur, ок, спасибо..

но зачем вызвать тот же эксцепшн и ничего не делать я так и не понял...

kostyl, есть просто случай где в том блоке по цепочке высше(методу который вызвал клиент, в свою очередь) нужно кинуть ексцепшн того же характера, (без изменений) который относится к апишному методу... Например если апишный может кидать IllegalArgumentException/IllegalStateException, то клиент, в свою очередь являясь лишь составной частью вызова целой цепочки методов из разных классов должен передать высше то исключение, чтобы прекратить работу в случае высшеописанного исключения... а не просто выйти по типу return.
 
Была идея(очень плохая), исходя из того что апишный метод может кидать 3-4 исключения, то в клиентском методе реализовать возвращаемые числа соответствующие тем исключениям. Тоесть если у нас в клиете -  IllegalArgumentException, то он буде возвращать -1, если IllegalStateException - -2, и т.д...
Но идея потому и плоха, что раз мы долбим код в стиле ООП, то лчше придерживаться тех же исключений, но делегированных. Та и к тому же нужно дополнительно все расписать согласно документации - какие возвращаемые числа что значат, либо пообъявлять константы с соответствующими именами.. Нехорошо так...

Rotten, тогда наверно правильнее будет сделать так: