Incorrect relationship keys give unclear error

[GwendolenLynch]

The following seems to fail silently in 2.x

persons:
  name: Persons
  singular_name: Person
  fields:
    first_name:
      type: text
      required: true
      label: "First name"
    last_name:
      type: text
      required: true
      label: "Last name"
    slug:
      type: slug
      uses: [ first_name, last_name ]

blog:
  name: Blogs
  singular_name: Blog
  fields:
  relations:
    person:
      multiple: true

In master it throws the uninformative:

Bolt - Fatal error.
Class: Bolt\Exception\StorageException
Message: Attempted to load mapping data for unmapped class person
Code: 0
Bolt\Storage\Mapping\MetadataDriver->loadMetadataForClass()
[root]//src/Storage/EntityManager.php, line 256
array:1 [▼
  0 => "person"
]

[rossriley]

We probably need to work out a strategy for dealing with these errors, and it depends to a certain extent whether we want to provide UI feedback, or fail with an Exception.

At the point this exception is thrown then the error is technically correct, in that it's identical to what you'd receive if you did: $repo = $app['storage']->getRepository('nonexistentitem') whereby the MetadataDrive would lookup nonexistentitem and declare that nothing could be found assigned to that item.

What we can do is either throw more precise exceptions in the same location (eg )...

Bolt - Fatal error.
Class: Bolt\Exception\StorageException
Message: Attempted to load mapping data for person defined at 'contenttypes.yml line XX'

Or we can extend what we currently do in Config.php eg: https://github.com/bolt/bolt/blob/master/src/Config.php#L445-L458 and add more parsing errors and throw LowlevelExceptions...

thoughts?

[GwendolenLynch]

I'm curious to get @bobdenotter's view on this.

The backender in me says that throwing the more descriptive error is OK… but… it does make a site rather fragile while being worked on… save you new work-in-progress ContentType and your whole site blows up… But I build these things on bur-boxes first anyway.

[bobdenotter]

Fixed in #4852