"красивый" вывод исключений и ошибок.

2Sergey89
а теперь сравни

PHP:

1.  <?php
2.  // ...
3.     try{
4.             MailService::create()
5.                 ->setTo($form->getValue('email')) // вот тут так и так выскочит ошибка, зачем еще раз это- же самое проверять в валидэйте. лишнюю работу делать хачешь?
6.                 ->setSubject('Hello');
7.                 ->send(); // если там не выскочит, то тут уж по-любому
8.     }
9.     catch(ServiceException $e ){
10.         //обработка исключительной ситуации
11.     }
12.     catch(Exception $e){
13.         //простор то какой!!!
14.     }

обрати внимание, что ты не только обрабатываешь ошибку "не ввел е-мэйл", а еще и все остальные ошибки о которых и подумать не мог.

- сервер отключили
- пропал интернет
- удаленный комп не доступен
- третяя мировая началась

все при помощи одного механизма. и при всем при этом. как не странно, затрачиваешь меньше усилий, потому что не делаешь рекваред полей и валидат формы. странно да?

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

 

почему альтернативные? у меня методы правильные. альтернативные это у тех, кто как-то по-другому делает

 

ИМХО в той же JAVA исключения повсеместно юзаются и для тех ошибок которые в голову программисту обязательно придут. Но так удобнее, а в большинстве случаев человека время стоит дороже машинного времени.

 

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

Покажи мне код обработки 10 полей формы? Причём нужно вывести ошибки для каждого из 10 полей. Ещё я хотел бы узнать какая именно ошибка произошла и хотел бы установить своё собственно сообщение.

 

раз уж заговорили об исключениях, хочу прояснить картину. как известно, сначало то были только одни ифы. а ислючения появились уже намного позже. Никто не спорит что можно обрабатывать ошибки при помощи ифов. В четвертом ПХП только так и делали. И ничего все работало. Но вот наконец появились исключения. Они как бы отобрали часть работы у ифов. Совершенно определенный кусок. то что раньше писали

PHP:

1. <?php
2. if ($mailer->send()) then{
3. }
4. else{
5.     //обработка ошибок
6. }

теперь пишут

PHP:

1. <?php
2. try{
3.     $mailer->send();
4. }
5. catch(Exception $e){
6.     //обработка ошибок
7. }

Вот из- за того, что одну и ту же вещь можно написать двумя разными способами и пошли эти споры, в головах какая-то путаница, где использовать if then, а где try throw catch. еще эти страшные тормоза, о которых говорил kostyl, вообще все усложняют. При всем при этом место, где должно стоять исключение видно в темноте и за километр. Никакой путаницы в этом нет.

вот есть. к примеру, функция send(). надо просто задать себе один вопрос "что является результатом нормального завершения этой функции?" можно сказать, что результатом нормального завершения этой функции является отсылка указанного письма на указанные адреса со всеми аттачами и копиями. А все остальные завершения- это уже не нормальные и они должны выбрасывать эксепшен. неслучайно, что в ПХПДок исключения стоят сразу за описанием функции, потому что одно вырастает из другого. Согласен тут с akrinel, что это надуманное деление на какие-то обычные ошибки, которые можно было предусмотреть, и совсем уж исключительные ошибки, которые должны выбрасывать исключение. Все ошибки равны. Она помешала нормально завершиться функции? помешала. этого достаточно. значит это уже исключение.

 

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

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

 

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

Странно, но я чётко понимаю где надо выбрасывать исключение, а где возвращать результат работы.

 

Поделись, пожалуйста, с общественностью, не все понимают. Я, например, нифига не понимаю.

Чем это:

PHP:

1. <?php
2. $mail = new Mail;
3. $mail->to([email='user@example.com]'user@example.com[/email]');
4. $mail->body('Кучеряшки.');
5.  
6. if (!mail->send())
7.    echo 'Мыло не послано:'.$mail->error;

Хуже этого:

PHP:

1. <?php
2. try {
3.     $mail = new Mail;
4.     $mail->to([email='user@example.com]'user@example.com[/email]');
5.    $mail->body('Кучеряшки.');
6.    $mail->send();
7. catch(Exception $e){
8.    echo 'Мыло не послано:'.$e;
9. }

И нафига оно ваще.

Мыслями если поделишься буду рад. Можно полезными, на твой взгляд, ссылками.

 

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

...

 

lexaпопробуй, если не сложно, в обоих примерах померить память.... мне просто интересно

 

2Sergey89
ни разу пока не откозывался от удобного инструмента только потому, что он медленно работает. мне по барабану. пусть компьютеры работают. я и так много работаю.

на своем горьком опыте я пришел к заключению, что бизнеслогика должна отделяться от интерфейса. и пришел я к этому не от мвц а наоборот от этого к мвц, а от того, что меня стали закалебывать консольными приложениями. это меня выдресировало. поэтому я и советую другим представлять как себя будет вести класс в консольном приложении, даже если это никогде не будет консольным приложением. если у тебя прикладной класс не умеет работать кроме как в форме или умеет, но приучен получать данные в двойных слешах или что еще хуже работает и при этом что- то ищет в $_REQUEST (реально такое было ), то консольного приложения к сожалению не получится. Обработка ошибок внутри моделей- это лишь одно из звеньев такого отделения. форму убрал- ничего не должно сломаться.

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

PHP:

1. <?php
2. /**
3. * @param int $x
4. * @parem string $y
5. **/
6. function move(x, y=''){
7. }

то я по-любому ожидаю от пользователя как минимум один парам и причем именно инт, а не стринг или еще что по-хуже. то есть на форму возлагается проверка количества и типа данных. после этого она передает их внутрь движка и движок уже оценивает их прикладную пригодность. То есть например x должен быть больше 100 по-любому. Вот тут и возникает соблазн проверить x на это условие еще в форме. Потому что кроме как из формы эти данные как будто поступать все равно не будут. Это и есть смешение интерфейса с бизнеслогикой! прикладная корректность должна провериться внутри модели и если что сообщить об ошибке, естественно, в виде исключения. А о том как можно легко передать исключение из движка пользователю, я и написал в первом посте.

Резюмируя все это, можно сказать, что лично я пришел к неутешительному для нас всех правилу: корректность данных должна проверяться в двух местах. И в форме и в модели. Причем в форме тип и количество, а в модели на прикладную пригодность. Правда опыт подсказывает, что проверку в форме чаще всего можно опустить, потому что без правильного количества модель все равно ругнется.

 

2Psih
вот как раз то, о чем я говорил. хороший пример того, как бывает, когда бизнеслогика смешана с интерфейсом.

 

alexey_baranov
лично я не пишу консольных приложений, и поэтому проверяю не в модели ввод пользователя... Думаю в безвыходных ситуациях можно использовать исключения для передачи управления в другую точку программы, но явно не так как пример у Psih...
Я обычно ставлю исключения для отлавливания своих ошибок и пишу их в лог или куда то там... Например, нет соединения с бд..., а проверять empty($_POST['tpl_name'] с помощью исключений, я считаю излишеством...
Очень интересно услышать мнения 440Hz и флоппик.... Жду с нетерпением...

 

согласен, но я же оговаривал тот, что попроще...

 

2Psih
а фотки где? фотку тоже давай. покажи как пользователь узнает об ошибке. такие же две фотки как у меня. сначала перед отправкой, потом как получил ошибку.

 

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

 

2Psih
А ты не думал о том, чтобы делать мвц, но только как бы в одном классе? То есть если в мвц

PHP:

1.  
2. <?php
3. class Template extends Model{
4.     public $name;
5.     public $master;
6.     public $born;
7.  
8.     public create(){}
9.     public delete(){}
10.     public rename(){}
11. }
12.  
13. class TemplateView extends View{
14.     function show(){}
15. }
16.  
17. class TemplateCont extends Cont{
18.     function init(){}
19.     function action{}
20. }

сделать вот такой гибрид

PHP:

1. <?php
2. class Template extends Component{
3.     public $name;
4.     public $master;
5.     public $born;
6.  
7. //model
8.     public create(){}
9.     public delete(){}
10.     public rename(){}
11.  
12. //view
13.     function show(){}
14.  
15. //action
16.     function init(){}
17.     function action{}
18. }

 

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

PHP:

1. <?php
2. class Request extends Object{
3.     function validate(){
4.         $details= array();
5.  
6.         if (!$this->property['text'])
7.             $details['text']='Заполните поле "Причина обращения"';
8.         if (!$this->property['workobject'])
9.             $details['workobject']= 'Выбирете объект обслуживания';
10.         if (!$this->propertyByType(19978))
11.             $details['i1']= 'Поручите заявку хотя бы одной функциональной группе';
12.  
13.         //вот тут немножечко похимичить. всесто обычного throw new Exception сделать вот так          
14.         if ($details){
15.             $error= new ValidateException("Неправильно заполнены поля заявки");
16.             $error->details= $details;
17.             throw $error;
18.         }
19.     }
20. }

При этом соблюдено главное правило мвц бизнеслогика никак не зависит от интерфейса. Это дает колоссальное преимущество при наследованиях. К примеру я могу пронаследовать от этого класса регламентную заявку, у которой обязательно к заполнению поле "скан". А валидэйт написать так parent::validate() и плюс проверить скан. если поменяется валидэйт обычной заявки, поменяется и валидэйт регламентной. если проверять все в формах, такого не добиться и плюс конечно прикладные классы получаются немного зависимы от интерфейса.

 

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