I like to suggest that we introduce exceptions in the core of CMSimple_XH 1.7. I want to point out one particular use case, where it would have been really simplifying matters, if we had been able to use it for CMSimple_XH 1.6 (in the following I'm referring to XH 1.6.5, but the issue was quite similar in 1.6).
Consider XH_Controller::handleMenumanager(), which calls $pd_router->refresh_from_menu_manager(), which calls $this->model->refresh(), which calls $this->save(), which calls XH_saveContents(), which calls XH_writeFile(). Only the last function is able to tell whether saving succeeded, and therefore it has been necessary that all functions pass the boolean result along the call chain up to XH_Controller::handleMenumager, which actually displays an error message, if saving fails. That is clumsy and error prone, but even worse it is even necessary to know what's going on behind the scenes in XH_Controller::handleMenumanager. Otherwise, how should we know that $pd_router->refresh_from_menu_manager() only returns FALSE, if content.htm couldn't be saved? There may have been other potential errors, in which case we would have had to introduce some "advanced" error reporting (such as a string, or maybe an object).
Consider how simple that could have been solved with an Exception. No need to pass the result along the call chain. Just throw an exception, if the file could not be stored, and catch it in Consider XH_Controller::handleMenumanager().
Of course, the example is somewhat bogus, as the handling of the menumanager was not really used by XH 1.6, and it might be removed for XH 1.7, but certainly there are other use cases, though most likely not as complex as this one.
I do not have a concrete proposal, but a few points for consideration and discussion:
- It appears to be useful to define a basic exception class XH_Exception, which can be extended by plugins.
- It might be a good idea (or not) to localize the exception message as soon as an exception is thrown (doing so for the core; making it a convention for plugins).
- It might be reasonable to wrap most of the code in a try-catch statement, to be able to catch inadvertently uncaught exceptions, and to give a sensible error message if that happens. Otherwise an uncaught exception will trigger a fatal error, what still might be somewhat useful -- or even more useful, as at least Xdebug would print a stack backtrace.