User tests: Successful: Unsuccessful:
An Exception may have been chained to include additional errors. If this is the case, the chained errors may help with debugging an issue. So when in debug mode, I suggest that our error templates display the error data for all Exceptions.
Enable debug mode.
You'll be testing each core template, in both the site and admin apps, and you'll also want to test the system templates (default error pages), to do that you'll need to temporarily rename the error.php
file in your active template to something else. Remember to give it back its original name when finished testing this.
Trigger the error page with a chained Exception (when creating an Exception object, pass the "previous" Exception as the third constructor argument). The previous Exception(s) should display when in debug mode with their stack trace after the main error is rendered.
Status | New | ⇒ | Pending |
Labels |
Added:
?
?
|
Category | ⇒ | Language & Strings Templates (site) |
Labels |
throw new Exception('Top Exception', 500, new Exception('Nested Exception'));
I left all these comments about using $this->_error
versus $this->error
and I still managed to screw that up. It's fixed now.
Yep working now. Imo it's a nice improvement, there are some valid use cases for nested exceptions
Yes, it shows both correctly,
not relevant to this topic, i hope something is decided for getFile() getLine() too that will show the line that the exception occured, thanks
Title |
|
No longer RFC, changes made to all core templates, please test.
@mbabker the test went well. But one thing is missing. I tested in admin templates (isis, hathor and system) and i get a JERROR_LAYOUT_PREVIOUS_ERROR not translated.
So i think you need to add that language var also to https://github.com/joomla/joomla-cms/blob/staging/administrator/language/en-GB/en-GB.ini
I have tested this item
It's appropriate in the template. Otherwise there will have to be additional public APIs to do the same. Plus, there should be zero output generated by helper methods, meaning the helper method would have to call JLayout, and now to override markup that was originally created in the template (either directly or through a method called by the template) you have to override a layout file. This is the cleanest approach.
I have tested this item
Thank you for the explanation
Status | Pending | ⇒ | Ready to Commit |
Labels |
Labels |
Added:
?
|
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-19 17:50:19 |
Closed_By | ⇒ | rdeutz |
Labels |
Removed:
?
|
Can you make this testing step to be more detailed, e.g. provide an example of file/line to change to trigger such an error, i don't understand it