incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: Executing SQL without the exceptions capability, to track SQL issues.
Date Sun, 22 Aug 2010 20:51:58 GMT
Hi exxos,

 

actually with Empire-db you can work with or without exceptions.

While we appreciate that exception handling is generally a good thing, it can occasionally
make code less readable and personally I think that many people do not use exception handling
properly.

 

Currently exceptions are disabled by default (which is something we might think about changing
in the future).

In order to turn on exceptions you must call ErrorObject.setExceptionsEnabled() in the startup
code of your application as follows:

// Enable Exceptions

ErrorObject.setExceptionsEnabled(true);

The example applications all have exception handling enabled this way.

 

With exception handling disabled (which is the default as mentioned before) the executeSQL()
will return -1 in case of an error.

In this case you can obtain the error Information by calling getErrorType () or getErrorMessage().

 

In any case executeSQL() will return the number of records affected by the operation. Hence
a return value of zero indicates that the operation succeeded successfully but that it affected
no records (which might be the sign of a logical error on your side but technically speaking
it indicates success).

 

Hope this was helpful.

Regards

Rainer

 

 

from: exxos [mailto:hatufr@gmail.com] 
to: empire-db-user@incubator.apache.org
re: Executing SQL without the exceptions capability, to track SQL issues.

 

Hi,

Could you tell us what were the motivations to avoid returning exceptions (SQL) for the methods
"DBDatabase.executeSQL()"?

This imposes to check if the returns is different of "0" or not. In case of equals to "0",
ask for the getErrorMessager() to get the report and advise the stack manually. While most
of theses exceptions, are the result of an unexpected and not acceptable state.

Often, in this specific case, most of developers will prefere throwing a new exception instead
of to propagate an "int" because this is not an expected functional behavior.

Could you please advise ? What is the purpose of that?

Regards,
exxos.


Mime
View raw message