You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@empire-db.apache.org by exxos <ha...@gmail.com> on 2010/08/21 20:16:26 UTC
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.
Re: Executing SQL without the exceptions capability, to track SQL issues.
Posted by Francis De Brabandere <fr...@gmail.com>.
Java has 2 kinds of exceptions.
* checked exceptions that you have to catch
* unchecked exceptions that can be ignored
Empire-DB has one exception EmpireException that extends
RuntimeException so it's an unchecked exception.
So catching this exception is all you have to do. in fact we could add
this exception to all javadoc and indicate it is only thrown when
enabled.
Personally I'd rather have methods throwing actual exceptions than
this ErrorObject approach... That's a whole bunch of methods that are
added to each Empire-DB object that makes the api harder and
non-java-like.
What are you thinking about Rainer when you say that exception
handling might change in the future?
Cheers,
Francis
On Mon, Aug 23, 2010 at 10:35 AM, exxos <ha...@gmail.com> wrote:
> Hi,
>
> Thank you for you anwser. I will have a look to this runtime configuration.
>
> But, juste a confirmation, I'm not able to see in the signature of the
> methods the "throw" declaration.
> Normally, when a method potentially returns an exception, this is mentionned
> in its signature.
>
> My question is, if I enable the exceptions using
> "ErrorObject.setExceptionsEnabled(true)", does this mean that executeSQL()
> will now return exceptions?
> Which exception is suposed to be thrown? "Exception" object?
>
> Regards,
> exxos.
>
>
> On Sun, Aug 22, 2010 at 10:51 PM, Rainer Döbele <do...@esteam.de> wrote:
>>
>> 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.
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
Re: Executing SQL without the exceptions capability, to track SQL issues.
Posted by exxos <ha...@gmail.com>.
Hi,
Thank you for you anwser. I will have a look to this runtime configuration.
But, juste a confirmation, I'm not able to see in the signature of the
methods the "throw" declaration.
Normally, when a method potentially returns an exception, this is mentionned
in its signature.
My question is, if I enable the exceptions using
"ErrorObject.setExceptionsEnabled(true)", does this mean that executeSQL()
will now return exceptions?
Which exception is suposed to be thrown? "Exception" object?
Regards,
exxos.
On Sun, Aug 22, 2010 at 10:51 PM, Rainer Döbele <do...@esteam.de> wrote:
> 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.
>
re: Executing SQL without the exceptions capability, to track SQL issues.
Posted by Rainer Döbele <do...@esteam.de>.
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.