- - - By CrazyStat - - -

5. July 2018

PHP: trying to catch an Exception, but it never gets caught?

Filed under: PHP — Tags: , , , , , — Christopher Kramer @ 20:24

You are trying to catch an Exception like this and it never gets caught?

try {
// whatever you do here
// probably, you use some library
} catch(Exception $e) {
// this never works

Most likely, your app is in some namespace. This means with the above code you only catch exceptions of the namespace of your app, not any exception. The solution is easy, just add a backslash:

try {
// whatever
} catch(\Exception $e) {
// this should work
// note the backslash!

Hope this helps somebody.


Try my Open Source PHP visitor analytics script CrazyStat.

4. May 2015

Typo3 6.2 and Crawler Failed opening required ‘PATH_t3libclass.t3lib_page.php’

Filed under: Typo3 — Tags: , , , , , , — Christopher Kramer @ 11:28

Typo3 6.2 with the current version of the crawler from TER (3.5) gives this error when executed by the planner from cron:

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_page.php' (include_path='[...]') in [...]typo3conf/ext/crawler/class.tx_crawler_lib.php on line 30

Or if you open the crawler module in the Info-Module, you get only a blank screen and these errors in the log:

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_pagetree.php' (include_path='[...]') in [...]typo3conf/ext/crawler/modfunc1/class.tx_crawler_modfunc1.php on line 30, referer: http://[...]/typo3/mod.php?M=web_info&moduleToken=[...]

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_pagetree.php' (include_path='[...]') in [...]/typo3conf/ext/crawler/modfunc1/class.tx_crawler_modfunc1.php on line 30, referer: http://[...]/typo3/backend.php

I found a bug report for this exists in the crawler bugtracker for over a year now. And the current crawler version 3.6.2 also fixes the problem, but for some reason is not in the TER yet. So to solve the problem:

Download crawler version 3.6.2 and replace “/typo3conf/ext/crawler/” with the contents of this archive.

Hope this helps somebody solving the issue faster.

4. October 2012

PDO / sqlite: database table is locked

Filed under: DBMS,PHP,phpLiteAdmin — Tags: , , , , , , , — Christopher Kramer @ 22:06

At the moment I am working again on phpliteadmin, a  php-based web GUI for database administration of sqlite databases. While debugging, I stumbled across a problem that only occurred with the PDO extension (not with SQLiteDatabase or SQLite3). I got the following error message while trying to drop a table:

HY000 / 6 / database table is locked

By the way, you can use PDO::errorInfo() to get these error messages. So as the error correctly explains, the table I tried to drop seemed to be in use. PDO documentation for PDO::query() also explains the problem (even though DROP TABLE statements are fired using PDO::exec()):

If you do not fetch all of the data in a result set before issuing your next call to PDO::query(), your call may fail. Call PDOStatement::closeCursor() to release the database resources associated with the PDOStatement object before issuing your next call to PDO::query().

So I hunted for the open cursor on a resultset of the table in question and could not find any. Finally, I found the SQL statement which still had an open cursor:

SELECT * FROM sqlite_master

Thinking about this, it is obvious: When querying sqlite_master, you request information about database tables. If one of the table gets altered or dropped, this might change the data listed in the resultset on which I still have a cursor.

Maybe this is a special case as usually you do not query sqlite_master a lot. But in case you do, this might be useful information.

To solve the problem, as the manual says, simply release the cursor using PDOStatement::closeCursor() before dropping/altering tables.