Сергей Протько: Погодите, такое ощущение, что вы упорно смотрите немного не стой стороны. Я ничего и не говорю про E_ERROR/E_USER_ERROR и им подобные. Я говорю именно про более легкие случаи. Я вам привел пример, в котором мне необходимо выкидывать наружу оповещение. Да, я вполне вероятно именно при помощи try/cache буду ловить ошибку из конкретного коннекта к гатевею. И вот, его поймав, я хочу положить в лог и системы мониторинга информацию о том, что коннекшен не удался и, после этого, подключаться к запасному варианту. Внешние системы мониторинга уже имеют кучу удобностей, например, как нотификейшены по превышению рейта ошибок (т.е. одна ошибка коннекта к основному гатевею - это норм, а вот 20 за последний час - уже проблема, может быть нужно искать другой гатевей). Я вас прошу привести пример именно замены этой нотификации и доставки такого рода информации в сравнении с уже реализованными решениями.
Сергей Протько:
> мой код падал потому что это возможный баг
Я бы был с вами полностью согласен, если бы хендлер того же yii реагировал еще на что-то, кроме стандартного error_reporting. Что бы можно было нотисы пропускать. Тем более нотис в продакшене не так страшен, как отказ обслуживания из-за него. Я лучше увижу этот нотис в системе мониторинга и спокойно его пофикшу, чем будут в панике разбираться, почему сервис из-за нотиса перестал работать совсем.
Так я прямо в вопросе и привел живой пример с необходимостью отлова некритичного события. И для его отлова уже давно была создана вполне удобная инфраструктура, включая кучу сторонних сервисов, которую в итоге и поломали. На голом php или фрамеворке, где E_NOTICE не роняет код добавление того же newrelic в модули php и одна строчка кода позволяют вам мониторить состояние бека в красивых графиках. А отсутствие необходимости хардкодить под систему мониторинга - позволяют легко использовать одну или другую не завязывая код на них. Сейчас же, что бы из yii бросить ворнинг (не убивая при этом исполнение) мне приходится кроме стандартного error_log вызывать еще и специфичные для мониторинга функции, что бы видеть эту ситуацию в графиках. На лицо ухудшение удобства при непонятных фишках в замен.
Нет, вы не поймите меня не правильно. Я так же вылизываю код, что бы там ни нотисов, не депрекатедов не вылазило. Но меня возмущает именно то, с какой легкостью убили удобное средство доставки информации. При этом я не вижу логики, почему бы те же E_NOTICE/E_WARNING не пропускать в стандартную очередь обработки, а уж E_ERROR и т.д. превращать в ексепшены.
Хм... вот это "правильно" я и не понимаю. Не спорю, что последние движения в php7 в сторону выбрасывания исключений вместо части ошибок - это гут, но это совсем другой плоскости вопрос. Я не понимаю, почему люди с легкостью отказываются от целого пласта удобного инструментария в угоду.... моде? И ведь не сами разработчики php E_NOTICCE и т.д. выпиливают. Просто такое ощущение, что кто-то не смог писать на старой парадигме и сказал: "Толкиен не прав, я знаю как было на самом деле!".
> вот как-то так. Далее уже нюансы. Если мы хотим юзать неблокируемое API
Эм... я не просил пример, как мне через try/catch разрулить отправку, я спрашивал, как мне в стандартную систему обработки ошибок кинуть E_NOTICE и так, что бы программа не прекратила работу.
Т.е. проблема в том, что вот имею я NewRelic или аналог который навешивается как error_hendler и всё радостно мне сливает в веб-интерфейс и мне удобно в коде, после пойманной ошибки о недоставки сообщения через основной гетвей просто кинуть trigger_error, что бы запись появилась в логе и в релике. Проблема вашего приведенного кода в том, что он не логирует. Да, вы можете сами руками вызвать тогда error_log, но это запишет только в лог пхп, но никак не в тот же релик. И получается, что вам придется городить огород для вызова еще и методов релика, что бы залогировать ту же ошибку еще и там.
> Symfony например так делает на php5.3+
Я с Symfony не знаком увы. Хорошо, если он не конвертит всё по дефолту. В Yii увы всё заворачивается в Exception без вариантов (и в Laravel похоже тоже).
Ну, может я и динозавр, но многие системы внешнего мониторинга (тот же newrelic) навешиваются как стандартных hendler и это очень удобно, пока ты не встречаешься с модными фрамеворками. И не понимаю, кто решил, что trigger_error с E_USER_NOTICE теперь не по феншую, оно ведь до сих пор не deprecated в php включая 7 версию. Т.е. на лицо изменение базового функционала без видимых на то причин, только потому, что модно.
Вы вопрос читали? Я не хочу ничего выводить, я хочу кинуть в лог (в сторонние системы мониторинга через стандартные средства). Я же сам этот ворнинг генерю, зачем мне его как ексеплен потом ловить, что бы потом еще раз с ним что-то сделать?
> error reporting level вы все еще контролируете.
Да, но это вызовет скрытие ошибки и от других хендлеров, а не только от хендлера фрамеворка.
> Ваша ситуация прекрасно разруливается исключениями.
Приведите пример пожалуйста.
> Научитесь пользоваться исключениями. В php7 в принципе даже ошибки парсинга теперь вызывают исключения.
Я не спорю, что в php7 всё ванильно и я бы ничего не писал, если бы yii1 работал бы только на php7 и вышел вот только что.
sanex3339: > Я пока использую решение через display: table у thead, tbody и tfooter, но до того, как применили display: table, циклом проходимся по всем td и th в table, запоминаем их ширину, после применения display: table, присваиваем всем td, и th сохраненные значения ширины. Более менее нормально выглядит, но пока еще есть небольшие косячки.
Мне такой вариант изначально не подходил, так как я хотел оставить связку th-td дивой, реализовав у себя контрол ресайза колонок без необходимости по кому либо пробегаться, а просто меняя ширину th.
sanex3339:
> *тут либо симулировать border-collapse самому* - поясните пожалуйста тут подробнее
В том плане, что по дефолту вы делаете у ячеек border: 1px... и у все таблицы collapse. А можно у ячеек делать бордер только снизу и справа, а у таблицы сверху и слева - эффект будет такой же (т.е. бордер в 1 пиксель везде), но при этом вы будете иметь у th бордер снизу, который не будет схлопнут из-за collapse.
С двумя оставшимися ошибками немного сложнее. Хотя они, как я понимаю, не являются обязательными, а только критичными. В любом случае, вам лучше обратиться к первоисточнику (сайт http://schema.org) и почитать, что это за свойства и для чего они.
