Refactor error/exception pages into an "Error handling" page

[Girgias]

This renames traditional errors to diagnostic errors Attempts to unify Throwable Errors with Exceptions Move throw, try, catch, and finally control structures to the control structure section

Feedback on this is very welcome and I'm open to suggestion, as some of the text still needs to be updated/improved. This is partly based on how Rust talks about error handling.

Some ideas I have also been considering:

• Split the two section in error-handling.xml into two files in a new subfolder error-handling/

A to-do list of sort:

• [x] Trim exception page
• [x] Maybe move extending exception page/trim it?
• [x] More examples in each specific section.
• [x] Create a new page in the control structure section for throw

Memo of things to do when this lands:

• Redirect previous pages to the new ones

[Girgias]

I think this is now ready for review, I hope I didn't remove any information by splitting it up.

[Crell]

Various small issues noted above.

My biggest concern is that this puts exceptions under flow-of-control... but exceptions, as we are told repeatedly, are not meant to be used for flow of control. Yet, they do change the flow of control. My concern is that, without any statement to the contrary, this could tacitly imply that using exceptions the same way you would use if, foreach, or goto is a-OK, when that's very much not the case.

Otherwise, everything else here seems reasonable.

[afilina]

@Girgias I resolved the outdated comments and provided my feedback on your own questions. I hope this helps to move this PR forward. I also applied the code suggestion with the syntax fix.

[Girgias]

Thanks, I'll try to get back to this, but I need to sort out HTTP redirection for php-web and rebase, I should have time again in September. :-)

[afilina]

This branch is getting old and has many merge conflicts. Suggestions:

• If conflicts don't require too much effort to resolve, resolve and merge as-is, fixing later as needed.
• If too many conflicts, convert it to a checklist ticket, then start new PRs with a smaller change at a time.

[afilina]

@Girgias Is it worth to keep this PR open? This looks like a slice that is too big to be feasible. It can be referred to in a ticket (todo) instead, so that you don't lose sight of some of the wording that might be reusable.

[Girgias]

@Girgias Is it worth to keep this PR open? This looks like a slice that is too big to be feasible. It can be referred to in a ticket (todo) instead, so that you don't lose sight of some of the wording that might be reusable.

I will try to work on this PR this months as I'm planning to start working on the Migration guide and do more doc works this month (as I also won't have access to my desktop with 24 cores which makes php-src work more annoying)

[afilina]

This PR hasn't moved in years. Would it make sense to open a new PR for just the added pages so it can be merged quickly, then work on changing existing pages over time, whenever people have time?

[kamil-tekiela]

This PR hasn't moved in years. Would it make sense to open a new PR for just the added pages so it can be merged quickly, then work on changing existing pages over time, whenever people have time?

Yes, reviewing smaller PRs is much easier. There seems to be very little reviewers available anyway, so the easier it is the better.