Целесообразность передачи исключений в методах. « Java

Сообщения: 2243 Репутация: N Группа: Адекваты

3 мая 2011 г. 14:11

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


try{
 objectX.doSomething();
}catch(SpecificForObjectXException){
 throw new SpecificForObjectXException();
}

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

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

vasa_c

Сообщения: 3131 Репутация: N Группа: в ухо

3 мая 2011 г. 14:17, спустя 5 минут 24 секунды

Что это? Ява?

В пыхе так:

} catch (Exception $e) {
   throw $e;
}

kostyl

Сообщения: 5210 Репутация: N Группа: Джедаи

3 мая 2011 г. 14:33, спустя 16 минут 15 секунд

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

Timur

Сообщения: 1068 Репутация: N Группа: Джедаи

3 мая 2011 г. 15:52, спустя 1 час 18 минут 42 секунды

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


void someMethod() throws SpecificForObjectXException {
  objectX.doSomething();
}

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

и вообще это и на Java не похоже

}catch(SpecificForObjectXException){ // где переменная?

master

Сообщения: 3244 Репутация: N Группа: Джедаи

3 мая 2011 г. 15:49, спустя 23 часа 57 минут 14 секунд

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



class DataBaseException extends Exception {}

class RowNotFoundException extends DataBaseException {}

try {
  foo();
} catch (DataBaseException $e){
 print 'проблема с чтением данных';
} catch (Exception $e){
 // какая-то ещё проблема
}


function foo(){
  try {
    readRow();
  } catch {RowNotFoundException $e} {
    print 'строка не найдена';
    throw $e;
  }
}

function readRow(){
  if (…) {
    throw new RowNotFoundException;
  }
}

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

не всё полезно, что в swap полезло

Rotten

Сообщения: 2243 Репутация: N Группа: Адекваты

3 мая 2011 г. 16:50, спустя 1 час 56 секунд

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

void someMethod() throws SpecificForObjectXException {
try{
  objectX.doSomething();
}catch (specificException e){
 // тоесть здесь можно ничего не писать икомпилятор поймет что в случае исключения 
 // нужно выбросить specificException ?
}

Абырвалг

Сообщения: 6480 Репутация: N Группа: Джедаи

3 мая 2011 г. 17:03, спустя 13 минут 8 секунд

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

Timur

Сообщения: 1068 Репутация: N Группа: Джедаи

3 мая 2011 г. 17:25, спустя 21 минуту 47 секунд

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

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

http://www.skipy.ru/technics/exceptions.html

Спустя 285 сек.

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

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

Timur

Сообщения: 1068 Репутация: N Группа: Джедаи

3 мая 2011 г. 17:32, спустя 7 минут 27 секунд

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

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

Rotten

Сообщения: 2243 Репутация: N Группа: Адекваты

3 мая 2011 г. 17:33, спустя 24 секунды

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

kostyl

Сообщения: 5210 Репутация: N Группа: Джедаи

3 мая 2011 г. 18:31, спустя 58 минут 26 секунд

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

Rotten

Сообщения: 2243 Репутация: N Группа: Адекваты

3 мая 2011 г. 20:07, спустя 1 час 35 минут 48 секунд

kostyl, есть просто случай где в том блоке по цепочке высше(методу который вызвал клиент, в свою очередь) нужно кинуть ексцепшн того же характера, (без изменений) который относится к апишному методу… Например если апишный может кидать IllegalArgumentException/IllegalStateException, то клиент, в свою очередь являясь лишь составной частью вызова целой цепочки методов из разных классов должен передать высше то исключение, чтобы прекратить работу в случае высшеописанного исключения… а не просто выйти по типу return.

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

kostyl

Сообщения: 5210 Репутация: N Группа: Джедаи

4 мая 2011 г. 11:58, спустя 15 часов 51 минуту 14 секунд

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

try {
 objectX.doSomething();
}
catch (SpecificForObjectXException e) {
 throw e;
}
catch (Exception e) {
 // Do somethink
}

Целесообразность передачи исключений в методах.

Войти