Как лучше всего справиться с ненайденными случаями магических методов PHP?

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

Примеры:

  • __get или __set, которые обращаются только к подмножеству свойств вместо произвольных имен
  • __call или __callStatic, которые ищут определенные методы или упрощают некоторые вызовы, вместо того, чтобы перенаправлять произвольные вызовы куда-то еще

Можно ли отправить запрос обратно в PHP для обработки, выдав соответствующее сообщение об ошибке?
Если нет, то как лучше всего имитировать исходную ошибку PHP «не найден»?

Идея состоит в том, чтобы скрыть детали реализации, которые я использую с помощью волшебного метода, чтобы разрешить чтение определенных protected свойств, и заставить объект вести себя стандартным образом, как если бы такого свойства не было. Та же идея применима и к другим случаям, таким как магия __set() и __call().


error-handling php metaprogramming magic-methods
person igorsantos07    schedule 31.05.2017    source источник
comment
Используйте trigger_error().   -  person axiac    schedule 31.05.2017
comment
да, но это все еще прослеживается как исходящий из пользовательского кода, так как лучшее, что мы можем сделать, это вызвать E_USER_NOTICE, отличный от внутреннего E_NOTICE.   -  person igorsantos07    schedule 01.06.2017
comment
Пока возникает полезная ошибка, вряд ли имеет значение, является ли это родным или пользовательским кодом. С какой целью вы пытаетесь скрыть свою реализацию до такой степени, что хотите подделать собственные ошибки? Любой, кто достаточно заинтересован, может легко проверить детали реализации в любом случае.   -  person deceze♦    schedule 01.06.2017
comment
но любой, кто не заинтересован, не должен привлекать внимание к странной стандартной ошибке. объект должен просто вести себя как обычный объект, у которого нет магического метода, который используется для открытия доступа для чтения только к паре защищенных свойств. почему это что-то плохое для запроса?   -  person igorsantos07    schedule 01.06.2017
comment
отредактировал вопрос, добавив дополнительное объяснение намерений   -  person igorsantos07    schedule 01.06.2017

Ответы (1)


arrow_upward
0
arrow_downward

К настоящему времени кажется, что лучшим поведением для геттеров/сеттеров является использование trigger_error(), хотя это еще не то, что хотелось бы, поскольку это все еще прослеживается как некоторая ошибка/защита, исходящая от пользовательского кода: нет никакого способа вызвать чистое уведомление, только уведомление пользователя:

public function __get($name) {
    if (in_array($name, $this->allowed_fields)) {
        return $this->$name;
    } else {
        trigger_error('Undefined property: '.static::class."::\$$name", E_USER_NOTICE);
        return null;
    }
}
person igorsantos07    schedule 01.06.2017
comment
Просто интересно, почему это требование: все еще прослеживается как некоторая ошибка/защита, исходящая от пользовательского кода: - person Jared Farrish; 01.06.2017
comment
потому что мне не нужно раскрывать эти свойства, полученные от волшебного добытчика. Это всего лишь деталь реализации с точки зрения API класса. - person igorsantos07; 01.06.2017
comment
почему ты это спрашиваешь? эта библиотека не имеет особых исключений. - person igorsantos07; 01.06.2017
comment
В наши дни я не вижу много необработанных ошибок PHP и уведомлений. Что я обычно вижу, так это выбрасывание и перехват исключений, которые можно обрабатывать там, где пользователь не видит деталей реализации. Поэтому мне было интересно, были ли вы в курсе того, как вы справлялись со своими ошибками. Ни здесь, ни там. - person Jared Farrish; 01.06.2017
comment
Я думаю, вам нужно следующее: set_error_handler() Похоже, позволит вам обойти бит E_USER. - person Jared Farrish; 01.06.2017
comment
не уверен, что понимаю, Джаред. set_error_handler() используется для написания... пользовательских обработчиков ошибок. Это все еще не позволяет мне подражать исходному поведению. - person igorsantos07; 01.06.2017
comment
Исключения также бесполезны, потому что это отличается от стандартного поведения, когда у объекта нет волшебного получателя. - person igorsantos07; 01.06.2017