done here

https://github.com/LimeSurvey/LimeSurvey/pull/2807

You have a simple example where it can be interesting ? I really don't seen any interest here.

1. In production : i prefer to show a white page than a error.
2. You can already have error log on production without show error (and leave debug to 0) : https://manual.limesurvey.org/Optional_settings/en#Logging_settings (not activated by default, because tmp directory is inside web access …)

That feature request related to silently down of app issue. That means - when we have any kind of runtime (dev, production, staging, testing) we will be able to see stack trace of exceptions in stderr (by default it's error log of web server). Of course in production it will be still white page. But for example - if it will be white page on client's machine and client will ask us what's going on? Will be way better to open error_log and understand what was wrong instead trying to reproduce it.

That means - when we have any kind of runtime (dev, production, staging, testing) we will be able to see stack trace of exceptions in stderr (by default it's error log of web server).
But for example - if it will be white page on client's machine and client will ask us what's going on? Will be way better to open error_log and understand what was wrong

But : your PHP error log already contains the error in all case ? No ?

I never have such case where i don't have any error … sometimes : hard to find because client ask me some days after …

You have a simple example where it can be interesting ?

Please: give a an update of code where i

1. Don't have any error in my PHP error log
2. Don't have any error with Yii logging settings

Where this is the only solution.

So, real example what happened with us recently:
mysql credentials was wrong and Yii app silently down in CI pipeline. Error logs was completely empty and say nothing. That try catch solution was help us.

According to solution - it's not only one brilliant solution. I am pretty sure we can do it in many ways. But this solution can be stronger than others because straight forward. According to Yii 1.1 approach (scripting approach). Will be way better to have general try-catch construction in index.php. It can guarantee us to catch some edge cases what was not catched for some reasons by custom exception listeners. Or maybe those listeners disabled for some reasons (for example because it's production).

Yeah, we run CI in debug 0 to make sure we use same assets as people in production. But sometimes that makes it's harder to debug, true. Hm.

mysql credentials was wrong and Yii app silently down in CI pipeline

With bad credentials we have clean 500 error with CDbConnection failed to open the DB connection (out of CI).

Web: see screenshot

CLI :

$ php application/commands/console.php updatedb
CException: DataBase version are not found, seems LimeSurvey are not installed. in /data/webdev/master/application/commands/UpdateDbCommand.php:36
Stack trace:
#0 /data/webdev/master/vendor/yiisoft/yii/framework/console/CConsoleCommandRunner.php(71): UpdateDBCommand->run()
#1 /data/webdev/master/vendor/yiisoft/yii/framework/console/CConsoleApplication.php(92): CConsoleCommandRunner->run()
#2 /data/webdev/master/vendor/yiisoft/yii/framework/base/CApplication.php(185): CConsoleApplication->processRequest()
#3 /data/webdev/master/application/commands/console.php(77): CApplication->run()

With or without your fix : i have exactly the same issue and no diff on error log

Capture d’écran du 2022-12-21 11-52-23.png (19,462 bytes)   

Capture d’écran du 2022-12-21 11-52-23.png (19,462 bytes)   

PS : for CI : https://github.com/LimeSurvey/LimeSurvey/blob/8aad2d351029cbd6cfd2a4b8648104a195b84b5c/tests/bootstrap.php#L223
no ?

So, you want to deny the fact that happened to us recently? Besides me, other developers have been involved in this problem and can confirm this.

Also the proposed improvement really helped in that situation.

So, you want to deny the fact that happened to us recently? Besides me, other developers have been involved in this problem and can confirm this.

I just want to understand why it's needed …

I just don't see any difference when testing myself …

Just understand , and understand too why the fix are not in /tests/bootstrap.php

I don't know why you can't reproduce it. Also, I expanded try catch coverage in index.php, just to be on safe side. What do you think?

Maybe i can not reproduce because i don't use the good step,
It's using CI only ?

Else about updating index.php used since a lot of time, yes i'm afraid of new issue in other server system …

With this issue we faced in CI only (as I remember). Also try catch operators is compatible with all known operational systems. It shouldn't have any side effects.

See https://github.com/LimeSurvey/LimeSurvey/actions/runs/3698492721/jobs/6264770444#step:8:2

Maybe a specific way with CI ?

Capture d’écran du 2022-12-22 17-03-16.png (91,208 bytes)   

Capture d’écran du 2022-12-22 17-03-16.png (91,208 bytes)   

Please check out my screencast video. In first try I tried to manage Exception without try - catch in index.php and log didn't contain anything. In second try I did the same but with try - catch construction and log contain error record. Level of severity was NOTICE but it can be fixed later. Fact of existence in log is obvious.

Please checkout my video https://drive.google.com/file/d/1RkIXEQs8rJhup_8PtiKTLtUm3Sru9w7Q/view?usp=sharing

I don't say it don't happen in specific situation … Commit can be merged, i just want to understand what is this specific situation …