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 Executing SQL without the exceptions capability, to track SQL issues.
Date Mon, 23 Aug 2010 10:15:22 GMT
Thanks for the explanation Francis.

Exceptions exist in all modern object orientated programming languages - but only Java has
so called "checked exceptions".
There has been a lot of discussion about this feature and personally I (as well as many others)
consider Checked Exceptions as a major design flaw of Java. This is also why you won't find
another programming language (at least as far as I know) that has a similar thing.
Here's just one article I found about this:
http://radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html

But while I understand that exception handling (with runtime exceptions) in general is state
of the art, Empire-db has the option to work without exceptions and idicating an error through
a return value instead. This is done for "expected" exceptions only such als SQLExecptions
(we would never catch an Out-Of-Memory exception or something). I think this is an acceptable
alternative an can help make sequencial code more readable.
 
When I said that error handling is something we can think about changing in the future I was
thinking about the following three alternatives:
1. leave everything as it is
2. leave the API but make exceptions the default (rahter than vice versa)
3. get rid of the return values and exclusively provide execptions for all errors.

Regards
Rainer

BTW exxos: I have still not found an optimal solution for your UNION with limit issue. This
is a very specific problem that will probably not affect many users but we'll sure have to
solve it. But I want a good solution not just a hack. So please be patient.

Francis De Brabandere wrote:
> Re: Executing SQL without the exceptions capability, to track
> SQL issues.
> 
> 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 <hatufr@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 <doebele@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.

Mime
View raw message