An exception always has a stack trace. It is a property of the root Exception class. The core templates all correctly render stack traces when debug mode is enabled.

Please provide further detail about what your issue is, right now there is no code issue or exclusion to be found based on this report.

Steps to reproduce the issue

Joomla! 3.8

• Add new custom module to your site
• Open: modules\mod_custom\mod_custom.php
• On line cca. 20 add:

$db = \JFactory::getDBO();
$query = 'SELECT * FROM #__contentX';
$db->setQuery( $query );
$db->loadObjectList();

The output is (see image):

Joomla! 4.0

• Add new custom module to your site
• Open: modules\mod_custom\mod_custom.php
• On line cca. 20 add:

$db = \JFactory::getDBO();
$query = 'SELECT * FROM #__contentX';
$db->setQuery( $query );
$db->loadObjectList();

The output is (see image):

No backtrace, no file, no row.

===========

3.8 should not have uncaught exceptions printing like that and the fact you have that screen print to mean indicates that something is turning off core's error handler. Both 3.8 and 4.0 should look like your second screenshot, but only when there is an error rendering the error page document (which, your query would do).

error rendering the error page document (which, your query would do).

In both J3.8 or J4.0, error in SQL query which is called inside the module doesn't load error page document for me. :-(

Hard to say, but I don't have any specific error handler set ? - both J3.8 and J4.0 run on the same server with the same settings - both clean installs - so for me hard to say, as the only one difference is the Joomla! version (3.8 <--> 4.0) ?

There are some behavioral differences between the global error handling in 3.8 versus 4.0. But what you're presenting as your 3.8 screenshot honestly should not be rendered at all because even if there is an error rendering the error page, that render process is wrapped in a try/catch and should result in something pretty close to your 4.0 screenshot at all times (minus on PHP 5 where the concept of a Throwable doesn't exist so it's still possible to get raw PHP errors to render like that). Basically, it should be next to impossible to get an uncaught exception error to display on the page like that screenshot once the Joomla environment is booted up.

Hi, it seems you are right, the displaying of the backtrace is different in another instance of Joomla!, so there is something which influences it ?

But the main problem still remains. In Joomla! 3.8 I get the backtrace, in Joomla! 4 I don't get it ?

You are never supposed to get the first screenshot and if you are then something is manipulating the global exception handler, that is outside what we're going to diagnose and troubleshoot on this repo (if someone calls set_exception_handler() and puts in their own handler, we can't do anything about that). The second screenshot is what it is supposed to be if you have a template without a custom error.php template and you get an error page with debug mode enabled.

Also keep in mind that in 4.0 the error document has been refactored to be a subclass of the HTML document type. This means the error template basically has the full HTML document capabilities, including being able to cleanly render all modules without any hacky tricks needed. So if you've got a module that is the cause of the error page being rendered in the first place, and that module is being rendered on the error page, you're in a recursive error loop and you're never going to get a rendered page (you're always going to get the "Error: Table ..." screenshot). We can't do anything about that one except hardcode a "no modules" condition into the error document, which is a pretty sucky answer.

The important question in this case is not how to display document error page when the error occurs in module but how to debug it with backtrace? So when developing module, how to get "right" debug information like it was set in J! 3.8 (when debug mode is enabled and error reporting is set to maximum/development)?

Enable logging and stop relying on the UI to tell you everything. In 4.0 there is now a specific plugin event triggered when an Exception goes uncaught in the application class, so you can use a plugin to do anything with that info, and the log statement that has been in the global exception handler for quite some time is still present. Yes, printing the stack trace is a convenient thing, but that is not the only way to get the data you need.

Unfortunatelly, my errorLog does not record any information in case of this error:

[16-Aug-2018 11:57:04 UTC] PHP Warning:  Invalid argument supplied for foreach() in \J4\components\com_content\Model\ArticlesModel.php on line 596
[16-Aug-2018 11:57:50 UTC] PHP Warning:  Invalid argument supplied for foreach() in \J4\components\com_content\Model\ArticlesModel.php on line 596

even my development tool not:

Seems I am to amateurish for this task, is there any info/documentation how to make debug including the backtrace now in J! 4?

Will be great to get some more info.

Thank you.

@PhocaCz Not sure but perhaps #20380 can help?

The Joomla logging API is what gets written to, not the PHP API. #10341 landed in 3.6.3, you just have to have a logger set up to catch that (turn on logging in the debug plugin).

There is no change to how error pages render in 4.0. The one difference that might make things a little harder is that error pages can more easily use modules in 4.0, and if the process of rendering an error page fails out (which includes a module having an error), instead of getting a themed page you get a basic "Error" message. This is nothing new, the error handler has had this type of behavior for quite some time specifically to make sure that the error handler triggering an error does not WSOD if error reporting is set to "correct" production values or potentially expose file paths if error reporting is more liberal.

I cannot replicate this.

I have enabled debug,
followed instructions to modify file of mod_custom to add the broken query
and i am getting the back-trace

I have similar config as yours
PHP 7.2.0 with 10.1.29-MariaDB

Tried both drivers, MySQLi and MySQL (PDO)

Also noticed in your picture of DEBUG parameter it shows green color
current CSS for switcher has some small bug and it is colorless ...

can you try to update to current head of the repository ? or better clone it again and then run
composer install
npm install
and delete libraries/autoload_psr4.php (just in case ...)

also you have said you tried with zero non-core extension installed
aka you do not have some other frontend template active ?

I don't use npm/composer, I use the latest nightly builds. Installed fresh Joomla! 4 ( https://developer.joomla.org/nightly-builds.html , 16 August):

• removed autoload_psr4.php (which was newly and automatically created again),
• no 3pd extensions installed,
• enabled debug mode,
• error reporting to development,
• only one template - Cassiopeia

the output is still same, raw text:
Error: Table 'j4nb.jos_contentx' doesn't exist: Table 'j4nb.jos_contentx' doesn't exist

In the circumstances you are creating, that is going to be expected as I said before...

if the process of rendering an error page fails out (which includes a module having an error), instead of getting a themed page you get a basic "Error" message

Short of hardcoding a "no modules" rule into the error document, this scenario can and will happen. Here is your issue. You have an error in a module that goes uncaught, this triggers the error page rendering. The error page tries rendering that same module, the module throws an error. The end result is you cannot get a "pretty" error page with everything rendered, you are going to get a generic "Error" with the exception's message. There is nothing we can do about that, and I would be rather hesitant about putting more rendering logic into the exception handler than absolutely necessary when it hits that bit of code because at that point it should basically be assumed that our API cannot be used to generate a response.

The error page tries rendering that same module, the module throws an error. The end result is you cannot get a "pretty" error page with everything rendered, you are going to get a generic "Error" with the exception's message.

I followed tip from @mbabker to have the module throwing the exception also being displayed in the error page (i modified mod_search which is also displayed in error page), and i got same behavior in J3,

no backtrace in J3 too

Hi, thank you very much @mbabker , @ggppdk

Based on your advices I discovered that when I "turn off" rendering of modules in document error page set by template it prevents from recursive error loop described by Michael, so in such case backtrace is displayed.

which exactly meets my needs. The question for me is why J3.8 worked the way for me I need but this is not important now, this issue can be marked as solved.

Thank you very much.

Closed as requested.

@PhocaCz if Issue is solved please close it, thanks.

@roland-d you disturb my Education. ;-)