cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <>
Subject [esql.xsl][Patches] imporve exception handling
Date Mon, 25 Dec 2000 08:32:11 GMT
Hello, everybody and especially Robin!
Merry Christmas! 
  (and Happy New Year -- as we celebrate this in Russia even more then Christmas! :)

May I speak about our taglibs -- and especially esql.xsl on such a busy time (Holidays and
all the stuff?)

Well, esql.xsl has gone a good way since its early versions, hasn't it? Well, it's current
flavour (1.39) is certanly nice and appealing! 
To make it even better and more usefull:

1) We get a wrong exception if an exception happens at attempting to establish jdbc connection:

when an exception is thrown in 

   _esql_connection.connection = DriverManager.getConnection(
then we get the wrong Exception. Instead of having an SQLException (smth like "Communication
link failure", what my driver throws)
we get a NullPointerException as the following code traps:

     } finally {
      if(!_esql_connection.connection.getAutoCommit()) {

(Actually _esql_connection.connection is null here!)

2) Guys, Plz! Can we have a way to catch this exception as we do in <esql:error-results>
for <esql:execute-query>?

I propose three variants of fixing these issues:

a)  esql.diff.1   -- is the most straitforward way of fixing the 1) issue 
b)  esql.diff.2   -- a better way of fixing 1) , support for doing 2) is provided
c)  esql.diff.3   -- I've imlemented esql:connection/esql:error-results. So this fixes both
1) and 2). (It's only my vision, of cource)

If you ask my opinion, I prefer c) > b) > a)

Robin, can we have this? 

Best regards,
with best wishes, may all your dreams come true in the New Year,
Tagunov Anthony
NNT Telecom Russia

P.S.  Actually in our production environment we're running our own dialect of esql.xsl --
a derivative of a very early esql.xsl.. and it's a shame
to loose all the improvements that have been made.. all the polishing of the idea and implementation
already in the "official" esql.xsl.. At the
same time, to be able to migrate to esql.xsl we need some of the features that we've implemented
in our own dialect in the "official" one.
I hope we may apply for future improvements, don't we ? We've got a couple more things we'd
like to see done in esql.xsl :)  -- without
breaking compatibility with what you have now too much of cource :))

View raw message