Eloquent: Accessing non-existing property SHOULD throw an error

[Michal-Mikolas]

Let's say we have model called Article with attributes (columns in DB): id, title, content, is_secret.

In the Controller let's simply pass data from DB to the view:

  public function articles(Request $request)
  {
      return view('articles.list', [
          'articles' => Article::all(),
      ]);
  }

and later in the template:

@foreach ($articles as $article)

  @if(!$article->is_secrel)  {{-- show content only if article is not secret --}}
    <h2>{{ $article->title }}</h2>
    <p>{{ $article->content }}</p>
  @else
    <h2>{{ $article->title }}</h2>
    <p><i>Sorry, this article is secret.</i></p>
  @endif

@endforeach

There is a typo (is_secrel instead of is_secret) which SHOULD throw an exception, warning or at least notice. I write "should" because this is how PHP behaves in every natural way and this is what normal PHP developers expect.

But Eloquent is like "Oh, you want to access attribute which doesn't exist? Hmm, let's just return null, that could maybe work."

The Problem

The only result of this behavior is that Eloquent helps to hide typos in the code. This could lead to bugs in the application and even security issues (e.g. if (!$user->is_blocked) { let them log in }).

The Solution

Eloquent should (after checking that for the requested name there is no database column, accessor, relationship etc.) by default notice the developer they probably made a typo.

[macropay-solutions]

You can put this in your model for that

    protected function getAttributeFromArray($key)
    {
        return $this->getAttributes()[$key];
    }

We wanted to add this functionality in our free crud lib based on your idea but the above solution is simpler.

UPDATE.

The above will throw on a not hydrated model and also on appends.

[macropay-solutions]

@Michal-Mikolas here you go a retroactive solution:

macropay-solutions/laravel-crud-wizard-free@8a2db8f

This will work in version 8->12 also for appends and not hydrated models and will not affect relations.

It needs error_reporting = E_ALL in php ini file.

BaseModel.php:

    protected bool $returnNullOnInvalidColumnAttributeAccess = true;


    public function shouldReturnNullOnInvalidColumnAttributeAccess(): bool
    {
        return $this->returnNullOnInvalidColumnAttributeAccess;
    }

    /**
     * @inheritDoc
     * @throws \Exception
     * @see static::returnNullOnInvalidColumnAttributeAccess
     */
    public function getAttributeValue($key): mixed
    {
        $return = parent::getAttributeValue($key);

        if (
            $return !== null
            || $this->returnNullOnInvalidColumnAttributeAccess
            || \in_array($key, $this->getColumns(), true)
        ) {
            return $return;
        }

        /** @see static::transformModelValue() */
        if (!$this->hasGetMutator($key) && !$this->hasAttributeGetMutator($key)) {
            try {
                return $this->attributes[$key];
            } catch (\Throwable $e) {
                throw new \Exception('Undefined attribute: ' . $key . ' in model: ' . static::class);
            }
        }

        return null;
    }

[Michal-Mikolas]

Thanks, but I am not looking for project-specific solution.

My goal here is to suggest how Laravel itself can be better framework for everybody, for every project. More helpful and safer by default.

[macropay-solutions]

@Michal-Mikolas Good luck with that (Just an example #51825)

[macropay-solutions]

@Michal-Mikolas Should we catch the Undefined array key "s" and throw a more explicit error message?

@aborza on our docker container

        try{
            $a = (object)[];
            echo $a->s;
        }catch (\Throwable $e) {
            echo $e->getMessage();
        }
        die;

results in

Undefined property: stdClass::$s

and

        try{
            $a = [];
            echo $a['s'];
        }catch (\Throwable $e) {
            echo $e->getMessage();
        }
        die;

results in

Undefined array key "s"

It all depends on the error reporting setup.
in out ini we have

error_reporting = E_ALL

https://php.watch/versions/8.0/error-display-E_ALL

Starting from php 8 E_ALL is the default.

[Sophist-UK]

On the whole I agree with the sentiment of the OP - the whole concept behind strong typing is to throw up errors when things are not done correctly - and providing a null as a value of a non-existent attribute is just asking for trouble later on.

However, Eloquent cannot easily change to throw an exception without creating backwards compatibilities.

Also, likely to apply to object types other than models.

So I think that Laravel should handle this as it previously has and provide an ability to turn on strict attribute name checking through a call in the app ServiceProvider.

[Michal-Mikolas]

Eloquent cannot easily change to throw an exception without creating backwards compatibilities.

Maybe in one of the next main versions?

provide an ability to turn on strict attribute name checking through a call in the app ServiceProvider.

Yes this would be the second best solution 😁

[aborza]

@Michal-Mikolas this is also the way PHP works: https://wiki.php.net/rfc/undefined_property_error_promotion, but that will change on PHP 9.0

[Michal-Mikolas]

If I understand right the RFC then PHP will become even more strict, warning user even stronger if they try to access undefined property. Right?

[aborza]

@Michal-Mikolas yes, now you will get just a warning and the value null when trying to acces an object undefined property, on PHP 9.0 it's going to throw an exception

[Sophist-UK]

I wasn't aware of this change coming in PHP 9 however there is no planned release date for PHP v9 so it is some way in the future (with 8.5 at the end of this year).

However, the current WARNING notices and future errors when attempting to access non-existent attributes will not apply to magic getters:

class User
{
    private string $name = "Robert PAULSON";

    public function __get($key)
    {
        if ($key == 'name') {
            return $this->name;
        }
    }
}

The real question is whether magic getters should do something similar or not. My gut reaction is that they should throw an exception for non-existent attributes however it does seem to me that one purpose (or possibly THE purpose) of implementing magic getters is to avoid this exact situation.

What do others think?

[aborza]

I would agree to go on a more strict mode to throw an exception in case the property / attribute is not defined.

[macropay-solutions]

It can be imposed via error_reporting = E_ALL, the default version starting from php 8.0.