Uncaught exceptions

[stormhike]

Summary

I am not able to catch exceptions in my code.

Step to reproduce

In code put:
try {
assert(2 < 1);
} catch (AssertionError $e) {
$this->modx->log(modX::LOG_LEVEL_DEBUG, “assertion failed”);
}

Observed behavior

Error is displayed on screen:
Fatal error : Uncaught AssertionError: assert(2 < 1) in …

Expected behavior

A log message containing “assertion failed”.

Environment

MODX: both 2.8.3 or 3.0.0, Apache: 2.4.53, MySQL: 10.3.34-MariaDB-log, PHP: 8.0.17, zend.assertions: 1, Vivaldi browser.
I have a php.ini in my base directory with:
error_reporting = E_ALL
display_errors = On

Using assert is just an example, none of my try/catch statements are catching any exceptions.
My understanding is that catching an exception locally should override any higher level error handler, like the MODX one modErrorHandler.
Any ideas?

[camicase82]

@stormhike

AssertionError

Hi there, if you run the same code directly on the server, I mean a .php file called from the browser are you getting the expected result?, also check this out, Assertions throw exceptions by default - PHP 8.0 • PHP.Watch

[stormhike]

camicase82, thanks for your reply.
That was a good suggestion. I ran a little php file and the assert did create an exception that I was able to catch.

So it looks like it might be something to do with MODX, so I’m in the right forum.

I am using PHP 8 so assert should throw an exception by default. And my other attempts to catch do not involve assert, they are related to PDO.

[joshualuckers]

My guess is a namespacing issue. Does the code below work?

try {
    assert(2 < 1);
} catch (\AssertionError $e) {
    $this->modx->log(modX::LOG_LEVEL_DEBUG, "assertion failed");
}

[stormhike]

joshualuckers, you are my hero!
Adding the namespace fixed the assert case and the \PDOException cases too.
Thank you.
I haven’t seen it needing the namespace anywhere in the PDO documentation, nor did it include the backslash in the fatal error message I got: Fatal error : Uncaught PDOException: SQLSTATE[42S02]:.

I guess we are in a time when namespaces are becoming the norm.
Thanks again, I can sleep tonight!

[joshualuckers]

We refactored the core in MODX 3 moving the classes from the global scope to namespaces.

If a class reference doesn’t have a prefix it’s considered to be a global class. For more info: Using namespaces: fallback to global function/constant

[stormhike]

joshualuckers,
Thanks for your help.

It still concerns me. In the page at your link it says “PHP will fall back to global functions or constants if a namespaced function or constant does not exist”. So I wonder why it is not finding AssertionError or PDOException from inside my own namespaced classes when neither of those constants are defined within my namespace.
That is assuming PHP looks in my namespace first, doesn’t find it, then looks for a global. If that wasn’t the case then we would need to put a backslash in front of every PHP built in function that we call.

What worries me is the possibility that code I wrote a while ago is no longer catching exceptions properly.

It’s not that it changed in MODX 3, it seems my exceptions went uncaught in 2.8 too.

[opengeek]

@stormhike

That is assuming PHP looks in my namespace first, doesn’t find it, then looks for a global. If that wasn’t the case then we would need to put a backslash in front of every PHP built in function that we call.

You must be explicit when referencing global classes within a namespace. In other words, you will need to prefix the global class with the backslash, or you will need to import it with the use keyword. Both AssertionError and PDOException are classes, not functions, so the fallback logic does not apply.