mybatis has no exceptions?

[Simon]

As far as I can tell from the userguide and writing some test code,
mybatis has no exception handling.

E.g:

SqlSession session = SqlSessionFactory.openSession();
PlayerMapper mapper = session.getMapper(PlayerMapper.class);
player = mapper.select(id);

Neither the getMapper, select, openSession throw any checked exception
accroding to eclipse, or the einterface definition.

What happens if you have a sql error? What happens if you lose
connection to the DB? Surely at least commit() should throw a sql
exception if the resource is busy for example? how would you detect
this case, and retry later, or tell the user who is locking the
resource?

Are all the exceptions throw converted to RuntimeException? If so,
are they documented anywhere?

Doing a grep for "catch" in the userguide doesnt find anyting, and
doing a grep for "exception" doesnt show anyting useful. Trolling
though the source, it would appear that IbatisException is a
RuntimeException, which would seem sacrelige. see:
http://download.oracle.com/docs/cd/E17409_01/javase/tutorial/essential/exceptions/runtime.html

i.e. if they are runtime, its not possible to know what excptions are
thrown by a method, toensure that they are dealt with appropriately.
I would argue sql exceptions are VERY important at the DAO layer -
e.g. to know if a commit failed because resource is in use requires
either 1) retrying a number of times 2) teling the user to try again
later 3) telling the user who is locking the resource etc. If I
search expecting say one row, and get multiple, I dont want an
uncaught RuntimeExcpeiton killing the whole app, I want to deal with
it whenever it can occur and inform the user.

If mybatis has no checked exceptions, this is a showstopper for me.
Has anyone tried hacking the code to make all excpetions non-
runtime?

Does Hibernate have the same problem?

[Jeff Butler]

A showstopper - really? I guess you can't use Spring either, because
it does a very similar thing. If you really need checked exceptions,
you should consider using straight JDBC code - it has all the checked
exceptions you'll ever need :)

Seriously - what would you do with an SQLException anyway - probably
just throw it again to the caller. Experience has shown that the best
thing to do is have a single high level exception handler (yes -
catching a RuntimeException) that logs, then apologizes to the user
and asks them to try again. There's not much else you can do in the
real world. There's absolutely no value in propagating checked
exceptions in hundreds or thousands of places in your code.

Jeff Butler

[Clinton Begin]

iBATIS uses unchecked exceptions for a few reasons:

1)  My personal design preference is unchecked exceptions.  Having worked with both C# and Ruby, I did not miss checked exceptions, and I even found that code was cleaner without them.

2) The SQLException class is terrible.  So at the very least we had to wrap it anyway.

3) All exceptions thrown internally are chained.  So you can always catch the unchecked PersistenceException (the base for all "normal" exceptions thrown by iBATIS) and navigate through the nested exceptions to find the SQLException

4) It reduces the chance of people writing code that unnecessarily or even erroneously catches and swallows exceptions.  Rather than a try/catch code pattern, a try/finally pattern is used.

5) SQLExceptions are generally unrecoverable.  The most you can do is write retry logic (still not usually a good idea), but you can still achieve that by following the nested exception chain as above.


Cheers,
Clinton

[Clinton Begin]

Of course I mean MyBatis.  LOL... that's going to take a while.  :-)

[Simon Hobbs]

Its hard to let go of checked exceptions after 10 years, but I see your points.

For us we check sql exceptions for 2 reasons:

1) Each customer has a lifetime value of thousands of pounds.  To throw a generic error message e.g. during account creation or deposit and losing that customer is not acceptable, unfortunately. & there is a lot of competition.

2) For each exception, we need to work out _roughly_ if it is:

   a) Worth asking the user to retry later  (e.g. timeout, db connection lost (so will be back again soon as we have 24x7 DBAs))

   b) An actual unrecoverable error (e.g. missing column, which should have been caught by QA), so tell them to contact customer services with the oracle error number and/or our own error numbers as a "reference number" (we dont use the word error) and what they were doing.  The Customer services team have a cheat sheet where they know if a certain error number occurs, they what to tell the customer, what they can fix themselves (e.g. by manually creating the account for them, or manually depositing the money), and what has to go to the development team to fix).

   c) A data error the user can fix themselves (e.g. unique constraint, missing value, too high a value).  Ideally, this logic should be in the front end validation, but its only the DB which can hard enforce it, and the business rules change all the time, unfortunately. (pesky Marketing Depts)

The application which uses the DAOs doesnt know anything about mybatis, so catching a myBatis PersistanceException would tie us into one implementation.  Our plan was to catch the PersistanceException in each method of each DAO, and re-wrap it into an application specific exception - a painful process.

[Clinton Begin]

If you're willing to check out spring, I belive they have already done
much of the work on this (for many frameworks).

Check it out, and maybe you can even just grab the code under the
terms of the apache license.

Clinton

--
Sent from my mobile device