What happened to my post yesterday? It has not make it to the list (May/Jun) so far. Here it goes, again:
Hi,
I believe an uncaught exception (thrown by the core PDO) does not tantamount to adequacy. Error handling is apparently inconsistent with some situations being handled and some being not. Refer:
Class: Zend_Db_Adapter_Pdo_Abstract
Line : 72-73 (possible uncaught exception handled well)
if (!extension_loaded('pdo')) {
throw new Zend_DB_Adapter_Exception('The PDO extension is required for this adapter but not loaded');
[Are the extension_loaded() validations for the specific database DLLs (eg: mysql, libmysql, php_mysql...) for the specific O/S by the specific class (eg: Zend_Db_Adapter_Pdo_Mysql), required, too?]
By the way, this is inadequate, too:
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://framework.zend.com/developer/ticket/74" target="_blank">http://framework.zend.com/developer/ticket/74
[Displays the username/password/etc... for the DSN in the client browser, if not handled]
I believe erroneous situations should be handled within the context of the originating/invoking class instead of letting them slip through the code and relying/depending on the higher level stack to handle them. A framework should function
independently - right out of the box!
By controlling-method, I meant the Zend_Db_Adapter_Abstract::query() because all the fetch*() methods as well as insert(), update(), delete()... invoke this method - and so the
single place to place the error-handling logic, non-redundantly (I don't mean to explain this to the framework developers, though).
Regards,
On 5/21/06, Art Hundiak <[hidden email]> wrote:
In a production enviroment the outermost code should always be surrounded
by a try/catch block to cleanly handle any exceptions that might slip
through lower level code. So in my opinion the current error handling is
adequate.
Maybe you could explain a bit more on what you mean by:
"The controlling method should be incorporated with the error-handling
logic."
> Apparently, there is not adequate error-handling in the db component
> (Zend_Db_Adapter_Abstract?). If MySQL is not running, the query() method
> throws an *uncaught *PDOException that is not a very graceful way to give
> up
> the ghost! The controlling method should be incorporated with the
> error-handling logic.
>
>
> I've reported earlier the _connect() method has the same missing try-catch
> logic problem, which if fails would dump a plethora of info (as per the
> docs) onto the client browser including the connection details such as
> userid/password... (and what not?) for the world wild web to see:
>
>
>
http://www.zend.com/lists/fw-general/200604/msg00054.html>
>
> Ticket # 73 (defect)
> Ticket # 74 (defect)
> Ticket # 75 (defect)
> Ticket # 76 (defect)
> Ticket # 77 (defect)
>
>
> Through over-sight, I submitted tickets 73-76 marking them as relating to
> the Documentation component. Somebody please relate them to the Zend_Db
> component.
>
>
> Thanks,
>
Locked
