[esql.xsl][Patches] imporve exception handling

[Tagunov Anthony <ta...@motor.ru>]

Hi, evrybody!

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 

===========
   Class.forName(String.valueOf(
      "com.intersys.jdbc.CacheDriver"
    )).newInstance();
          
   _esql_connection.connection = DriverManager.getConnection(
                String.valueOf(
      "jdbc:...://.../..."
    ),
                String.valueOf(
      "..."
    ),
                String.valueOf(
      "..."
    )
===========
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()) {
        _esql_connection.connection.commit();
      }
         _esql_connection.connection.close();
    }
============

(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,
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 :))