Зачем нужны throw Exception?

[fisher]

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

 

[john.brown]

fisher
И почему не валидация? Что не понятного и плохого в этом коде?

class MySaveController extends Controller {
	function execute($request) {
		try {
			$item = new ModelItem();
			$item->fillFrom($request);
			$item->save();
			$this->viewArgs['message'] = 'Item saved';
			$this->view = new SaveSuccessView();
		}catch(ValidateException $e) {
			$this->viewArgs['item'] = $item;
			$this->viewArgs['errors'] = $e;
			$this->view = new MyFormView();
		}
	}
}

 

[tenshi]

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

 

[john.brown]

tenshi
Конечно одно для всех полей сразу. Какой смысл бросать исключения на каждое поле?

 

[tenshi]

чуть выше тут вроде поля предлагали так валидировать

 

[john.brown]

tenshi
Да нет, это не валидировать предлагали, а в QuickForm поля добавлять предлагали с перехватом отсутствуюущих типов. И, имхо, вполне оправдано предлагали

 

[zerkms]

Валидировать формы не совсем оправданно, потому как состояние "форма невалидна" - ожидаемое. Оно такое же ожидаемое, как и "форма невалидна". В противовес исключительной ситуации, когда поток приложения нарушается ввиду каких-то непредвиденных и ненормальных причин.

 

[AmdY]

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

 

[john.brown]

zerkms
Любое обработанное исключение ожидаемое. Ибо программер ожидал его и написал соответствующий обработчик для этой ожидаемой ситуации. А непредвиденные ситуации или вообще не обрабатывается, или обрабатывается каким то эррорхандлером, всунутым "на все влучаи жизни"

А ситуация "форма невалидна" как раз, имхо, подпдает под исключение - нормальный "ход событий" будет создать объект, заполнить данными от пользователя, сохранить. Невалидность формы нарушает этот ход, и требует принятия мер по исправлению ситуации. Если учесть еще то, что валидация происходит "далеко" от контроллера, и без исключения придется городить какой то механизм, чтоб передать результат валидации контроллеру, то исклэчение самый подходящий способ.

-~{}~ 20.06.10 15:57:

AmdY
Ну, да, модели. Но зацикливаться именно на саму форму, т.е. $_REQUEST, как то смысла не вижу, т.к. данные невалидными становятся токмо в контекстк конкретной модели. Значит логично валидировать именно модель, а не какую-то абстрактную форму.

 

[zerkms]

john.brown
Никаких горожений не надо - результат валидации валидатор отдаёт в любом удобном виде. посмотри в тот же Zend Framework.

Любое обработанное исключение ожидаемое. Ибо программер ожидал его и написал соответствующий обработчик для этой ожидаемой ситуации.

не совсем. обычно обработчики пишутся на результат "исключение брошено". какая была причина - часто неизвестно и неинтересно во время программирования.

Типичный пример:
try {
}
catch(FileIsNotWritableException $e) {}

У нас на руках результат - исключение конкретного типа, означающего "не можем записать данные в файл". А теперь озвучь причины?

В случае валидации формы у нас есть именно причины - пользователь неправильно заполнил конкретное поле.

 

[john.brown]

zerkms
Так и в случае "не можем записать данные в файл" есть в полне конкретная причина - или файла не сушествует, или права на файлу не те, или права на папку не те, или исчерпан лимит места. И в каждом их этих случаев могут быть разние методы реагирования, и, по уму, должны быть разные ексепшены. Т.е. тоже в полне ожидаемая ситуация. Не вижу разницы с невалидными данными от пользователя.

 

[zerkms]

есть в полне конкретная причин

она не определена статически. более того - все причины статически ты определить и не сможешь, и не нужно. а в случае валидации - причина одна и определённая.

 

[john.brown]

zerkms
Это начинает смахивать на холивар

AmdY на самом деле все выше написал, но поясню, как я это понимаю.
Валидация формы (т.е. $_REQUEST) само по себе безсмысленно - массив $_REQUEST всегда валиден. Невалидной может быть только модель, заполненная из этого массива. Соответственно, ее и надо валидировать в процесса сохранения, и ловить причины, по которым ее не удалось сохранить. А они могут быть разными, и одна из них - невалидные данные. Так же отсутствие таблицы, не соответствие полей таблицы модели, отсутствие конекта... Чем отличается от "не можем записать данные в файл"?

 

[fixxxer]

Иногда исключения действительно удобны не по прямому назначению. Но злоупотреблять этим не стоит.

peace!

 

[zerkms]

Соответственно, ее и надо валидировать в процесса сохранения, и ловить причины, по которым ее не удалось сохранить

ой не факт

пример: форма регистрации.
поле: пароль
ситуация: захотели добавить поле для конфирмейшна.
факты: эта логика не относится к модели, потому как модели поле "подтверждение"совсем не интересно - у неё даже нет поля для хранения этого поля
решение: валидируются исходные данные бесприменительно к модели.

пример 2: валидация емейла (на уникальность) через аякс
объяснение: тут у нас вообще никакая модель не заполняется и не пытается сохраниться, потому что из данных только 1 поле

пример 3: новый тред на форуме
объяснение: в этом случае у нас (обычно) в базе данных создаётся 2 записи: thread + post. и не совсем понятно - какая из моделей у нас должна быть провалидирована. создавать 2 и валидировать эксепшнами не получится - если одна из них прошла валидацию, а другая нет, тогда придётся удалять одну из них (дада, я в курсе о транзакциях и о роллбэке)

 

[Mols]

хз как с точки зрения "большой теории" но лично мне на практике очень удобно пользоваться библиотеками типа БыстраяФорма. Чтобы и валидировала и отображала ошибки именно библиотека. В модели тоже можно проверить и бросить исключение если что. Но не в качестве той ожидаемой валидации которая есть нормальным "диалогом" с пользователем. А именно в качестве обработки исключительной ситуации когда "такого в принципе быть не должно, но оно почему-то произошло"
З.Ы.
И уж точно не стал бы я делать 4 типа разных исключений при ошибке записи в файл. Если конечно заказчик платит не за количество строк)))

 

[john.brown]

zerkms
Пример 2, с точки зрения серверной стороны, вообще не валидация формы Это с точки зрения клиента валидация, а на клиенте философия несколько другая.

В примере 1 логика как раз к модели относится - это валидация поля модели "пароль" по контрольному значению.

 

[zerkms]

john.brown
ну да, если вообще всю логику, которая только может быть в приложении помещать в модель - тогда согласен, в модели ей и место.

 

[john.brown]

А какая там особая логика? В модели просто в правилах валидации прописывается еще одно правило - что типа

$this->rules->password->addRule(new isEqual($this->api->request->get('povtor_parolja')));

Экая сложная логика...

П.С. а валидацией занимается валидатор, а не модель.

 

[zerkms]

john.brown
при чём тут сложная или нет.
недавно ведь был топик о бизнес-правилах.

это как раз типичный пример бизнес-логики, о которой модель ничего не должна знать.

модель user и о капче, стало быть, должна знать?

-~{}~ 21.06.10 01:04:

П.С. а валидацией занимается валидатор, а не модель.

гхм, я как-то думал, что ты "за" валидацию моделью.
тогда твоя позиция оказывается совсем непонятной.

ты против валидации реквеста. но ты за валидацию "модели".
т.е. мы данные реквеста устанавливаем в модель и потом те же самые данные (но извлекая из модели) валидируем? в чём принципиальная разница?
а если у нас нет модели, например капча, то половину данных мы валидируем из модели, а половину из реквеста?

ps: кстати вот ещё: как мы можем заполнить модель данными, если мы даже не уверены, что данные там есть? (а если бы у нас был более строгий язык, то - если мы не уверены, что у нас данные нужного типа)