On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only catch in your outermost
handler. Is that correct? We were
Matt Sergeant wrote:
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only catch in your outermost
handler. Is that
On Wed, 10 Jul 2002, Perrin Harkins wrote:
Matt Sergeant wrote:
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only
On Wed, 10 Jul 2002, Matt Sergeant wrote:
Ah, in that case I'm recommending Dave's stuff. It's more flexible and
doesn't use that irritating -param stuff. Though I have to do a little
more research to be certain some things are possible (like turning on
stack traces globally).
Actually,
Perrin Harkins wrote:
We've actually discussed this on the list. It has to do with closures.
Matt gave a presentation about exception handling which covers it and
shows a workaround. You can see it here:
http://axkit.org/docs/presentations/tpc2001/
Sorry to chime in a little late on
Michael Schout wrote:
in other words, if I understand the eToys article correctly, the leaks
only happen if I nest a try block inside another try block. I have
experimented some, and it appears to me that this is in fact the case
($count doesnt get cleaned up if there is a nested try).
On Wed, 10 Jul 2002, Michael Schout wrote:
Perrin Harkins wrote:
We've actually discussed this on the list. It has to do with closures.
Matt gave a presentation about exception handling which covers it and
shows a workaround. You can see it here:
List,
Without wanting to fire up a huge thread about MVC seperation etc etc. I
just wondered if someone would share their expertise on the following
question.
Using Perrin's article on E-Toys is perhaps a good place to start. In the
Model object which performs various DB procedures, what
Richard Clarke wrote:
Using Perrin's article on E-Toys is perhaps a good place to start. In the
Model object which performs various DB procedures, what actions were taken
if for some reason the connection to the database failed or if an SQL error
happened? Was the whole execute() block put in
On Sun, 30 Jun 2002 12:58:08 -0400
Perrin Harkins [EMAIL PROTECTED] wrote:
: Well, naturally the answer is it depends. Most database errors can't
: be gracefully recovered from, so we would let them propagate up. If it
: was possible for a database error to be caused by user input (say, a
:
F. Xavier Noria wrote:
I remember the article has a comment regarding a gotcha of the Error
module that causes memory leaks, but you didn't go into details there.
We've actually discussed this on the list. It has to do with closures.
Matt gave a presentation about exception handling which
11 matches
Mail list logo
