This is an echange where Hans laid out his approach to error handling in Syntax CMS, and I added thoughts on error handling in general.

I know that error-handling, logging & the load that places on the server is becoming increasingly important. The error-handling/logging framework I adopted for GlobalEU should help eliminate excessive server load. Essentially, instead of sending an email or opening a log file each time an error is triggered, error messages (and debugging messages, if applicable) are collected and only written to the log file at the end of the script. I used PEAR's error handling classes -- with a small PHP function that served to pass all PHP errors through the PEAR error handling mechanism. My error handler, Site::errorHandler(), knows to re-direct to an error page if error is above a configuration-specified threshold (i.e. fatal) and otherwise (if the error level meets the 'logable' criteria) will simply add the error to the Log queue. That's all pretty standard. The different thing is that the log is only written at the end of the script. This is done by registering a shutdown function w/ PHP. My Site::shutdown() method performs all logging and any other cleanup actions, and is registered with PHP like this: $Site = &Site::singleton(); // b/c you can't register static methods register_shutdown_function(array($Site, 'shutdown')); Doing logging at script termination will mean that an error email or mysql insert will only happen once per script execution, and not once per every error on the page. (Though, I think Jo would prefer we not use either of those methods for error logging.)

My reply:

The other good thing about Hans's approach here is that provides a hook for explicitly handling errors for the user. This is something we're starting to do but can do more of. In my old classes, I would throw a warning as soon as an error occurred and then immediately return false from that function. The calling code would test for that, and either compensate or throw an error and return false itself, up the line until I got to the page level code, which would also verify that no function or method it called threw an error, otherwise it "handles" the error and triggers its own warning. So even if you don't replace PHP's error functions with your own (ideal), you can still explicitly handle things at the warning level and provide non-ugly recovery or a friendly notice to your users. Either way, we should be testing for failure and providing code that works in case of failure so our users don't see broken-looking or error-ridden pages.

Sadly, pxdb_* classes were not built with that level of error handling. Also, we found out that PEAR::Error is a huge performance hog, and we sped up the sites noticeably by ditching it...and additionally, we got more reliable error reporting, especially for warnings that should have been dealt with before sites moved to production. I think we need to move back to a Syntax CMS-level function that handles fatal errors (E_ERROR or E_USER_ERROR) and does the redirecting to an error page--but this time it won't be identical to the authentication failed page and the file not found (404) page.

Still going through my old inbox entries. This one talks about the history of filter classes and gives a bit of the rationale for the current design. Would it had been discussed a bit more (it could be smarter about left joins)...

From: hans@forumone.com Subject: [classes] next generation filtering Date: September 5, 2002 10:32:56 AM EDT To: dev@forumone.com Hi F1devers, For those of you who have used the f1db_filter class, I have a new f1db filter class available [built for PHlexDB, but does not depend on PHlexDB framework] that is infinitely more flexible. The current f1db_filters class has 1-level of filtering depth. I.e. you can filter on docs related to a given author, or on authors related to a given organization, but there is no way to filter on docs related to people who are related to a given organization. For BYJ, Sandy hacked the class to support 2-level deep filtering on picklists (I think it was to add ability to filter on X related to X that has a certain picklist value). The new filtering paradigm has no limitations on levels of depth. Also filter components can be re-used & re-combined to produce different result sets. It's pretty slick -- I've used this filtering framework extensively on new project spaces "intranet" page, where you will be able to see, e.g., all documents which are related to a project of which you are a member. Additionally, the new filtering class is actually a "search" class -- you can choose whether you want to filter (i.e. 'exclusive') or search ('inclusive') the records table. Bear this in mind if you think you could use more flexible filtering systems in a project. Cheers, Hans

Was cleaning out my inbox and found this note from the PhlexDB days. I figure it's worth capturing here, as it still applies to Syntax in its current form.

There's been a couple of questions about prefix & path in PHlexDB. Because PHlexDB doesn't rely on any values set in scripts, it uses the pxdb_prefs ("preferences" tab in DBasis) table for things like the file upload prefix and path. It is looking, in particular, for 2 preferences: [name] [key] [value] 'datastore' 'path' '/var/www/vhosts/etf.www/private/files' 'datastore' 'url' '/files/' Using the pxdb_prefs class in conjunction w/ documentInfo: $prefs = &pxdb_prefs::singleton(); $docInfo->set_local_filestore_path($prefs->get_pref('datastore', 'path')); $docInfo->set_local_filestore_prefix($prefs->get_pref('datastore', 'url')); A general note about the preferences class. It's a pretty simple table structure (3-cols) & it's indexed, so while there is someoverhead in getting values out of this table, it's not very large. **Also, preferences are cached so that subsequent requests for the same pref on a page have no db call. You can store whatever values you want in the pxdb_prefs table (you can use add_pref(), set_pref(), or set_default_pref() methods). It's purpose is to allow several web apps (e.g. admin areay, dbasis tool, and public site) that share the same database to know about site-specific settings. Cheers, Hans