Чем отлов исключения принципиально добавляет макаронности той же самой проверке вернувшейся из функции переменной? вы реально считаете, что проверять на is_string, а потом парсить строку на содержание что бы понять, что с ней делать (логировать или пользователю выводить) удобнее чем отловить исключение, в котором будет код и тип ошибки помимо сообщения? Я правда не понимаю, о чем мы спорим

Зачем парсить? Вы знаете что это ошибка при чем ошибка наперед известная (неверныая комбинация логина или пароля) вот и выводите

а пятиэтаэный
catch(...)
catch(...)
catch(...)
catch(...)
catch(...)

в каждой функции чем лучше

я уже не говорю как такую бизнес логику отлаживать

Если ошибка наперед известная - то и катч будет тоже 1 ... вы явно пытаетесь отмазаться ))

если у вас одна ошибка(неверная комбинация логина и пароля), то и catch будет один.
А получение экземпляра класса User и его проверка в коде на принадлежность к этому классу вызывают недоумение.
Меня вообще с момента начала изучения слегка напрягает возможность возвращать смешанное значение в PHP, это подразумевает, что после вызова функции я должен ещё и проверять, что же она мне вернула... неприятно.

во первых не один - у вас могут быть иклблючения по работе с БД

во вторых что проще и читабельнее

if(_)

или


try{


...



}
catch{

}




вы проверяете не принадлежность а что это класс (можно использовать is_class) а не строка

или можно наоборот проверять что строка -
здесь два варианта и простой if

Т.е. спор идет о том, что возвращать из статической функции?
И кошерно ли возвращать что-то неизвестного типа (объект или строку или бул)?

чего оно неизвестное если это ваш код

даже если не ваш - это PHP у него исходники перед глазами даже если нет описания функции это не скомпилированая библиотека

если говорить про конкретно этот случай, то catch будет один, потому что обычно абсолютно всё равно, какая причина помешала пользователю залогиниться, результат один - в логине отказано. а если нужно обрабатывать разные ситуации, то catch будет больше, но и IF в вами предложенном решении будет больше ( в самом деле, не будете же вы писать пользователю, что у вас база данных померла.)
по поводу читаемости - тоже прихожу к мысли, что try{}catch{} становится читабельнее, потому что ожидаешь, где искать обработку ошибок, а не выискиваешь её в каждом встречном if.
и catch(SQLException e) выглядит, кстати, красивее, чем if(!is_class($variable) and $variable =="не удалось выполнить запрос");

И вот тут тоже что-то не понял.
А если объект это лютое сочетание 5-ти запросов к БД? Где мне все эти запросы делать?

Ну как пример: а что если это экземпляр скажем такого милого класса как "cisco"?
С бородой интерфейсов (которые ессно достаются из других таблиц) и таких не менее веселеньких экземпляров класса channel?
Где, как не в конструкторе их все инициализировать?

-------------------------------- -
Хотя идея со статикой ГУД!
(Добавление)


Интуитивно хочется запихнуть всю сложную логику внутрь класса и забыть. А потом уже с "понтом под зонтом" экземплярами жонглировать.
Т.е. хочется только помнить что у каждого класса есть статический метод типа check который вернет либо обьект, либо сигнал о проблеме. Вопрос в том в каком виде этот сигнал получать. Хотелось бы конечно однообразия и однообразия академического.

Не все равно
ошиька БД это одно
неверный пароль это другое
пароль верный но expired это третье





В методе логин и делаете где же еще? Этот метод выполняет конкретную функцию в бизнес-логике. Количество запросов не имеет значения





если кроме инициализации переменных класса - то есть присвоения им значения производятся еще какието действия вычисления и т.д. тогда конечно нужен конструктор
в данном случае речь шла о присвоении полей таблицы БД полям класса
(Добавление)


да, только сигнал это не исключение которое будет поймано неизвестно где
а если оно поймано тут же то на фига оно надо если можно обойтись IF



нужно пользоватсыя здравым смыслом и пракьтическим опытом а н не выкладками теоретиков
(Добавление)
Это PHP приучает так писать безалаберно

писали бы вы на С++ такие ноимера бы не прошли
выкинули исключение с класса а класс остался в памяти
(знаменитая memory leak)
через пару дней бы сервер остался без памяти а еще пару дней бы ушло найти где проблемма

это значит, что исключения развивают безолаберность, а нетипизированность возврата функций - наоборот, ведёт к духовному и профессиональному росту?)

Не, с мнением что исключение это не гуд в данном случае я согласен.
Наверное ОБЩИМ для всего можно признать принцип: если статик класса вернул что-то типа "не экземпляр" то значит бяда, что-то не так.




К сожалению у меня такое только в виде счастливого исключения будет встречаться.

И не надо давать методам дурацкие названия типа check или valid
Логин есть login понятно что он делает

+100500!!
Причем логин юзера это случай "детский".

Да, но что именна за бяда вы уже знаете метод уже это определил тут ничего не надо делать просто вернуть сообщение клиенту
это не исключительная ситуация




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