[db] query() method bombs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[db] query() method bombs

Shekar C Reddy
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:
 
 
 
 
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,
Reply | Threaded
Open this post in threaded view
|

Re: [db] query() method bombs

Art Hundiak
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,
>


Reply | Threaded
Open this post in threaded view
|

Re: [db] query() method bombs

Jayson Minard (ZF)
In reply to this post by Shekar C Reddy
Re: [fw-general][db] query() method bombs I moved them to Zend_Db, thanks for actively reporting issues!

--j


On 5/20/06 7:24 PM, "Shekar C Reddy" <[hidden email]> wrote:

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 <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,


Reply | Threaded
Open this post in threaded view
|

Re: [db] query() method bombs

Shekar C Reddy
In reply to this post by Art Hundiak
Hi,
 
I fail to understand why an uncaught exception (thrown by the core PDO) tantamounts 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)
 
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 (mysql, libmysql, php_mysql...) for the specific O/S by the specific class (eg: Zend_Db_Adapter_Pdo_Mysql), required, too?]
 
Do you think this is adequate, too:
 
 
[This 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 on the higher level stack to handle them. 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,
>



Reply | Threaded
Open this post in threaded view
|

Re: [db] query() method bombs

Shekar C Reddy
In reply to this post by Art Hundiak
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,
>