Re: MySQL and MSSQL in same java application

Am 20.11.2014 um 09:42 schrieb anthony berglas [email protected] 
[SimpleORM]:
> P.S.  Yes, checked exceptions are a particularly awful idea because they
> encourage people to gobble exceptions, as do the standard Java libraries.

Yup. They should have added discriminated unions (aka sum types aka 
algebraic data types) and structural pattern matching instead. If a 
function that can fail in a way that must be handled returns a
   FileOpenResult: Fail | FileHandle
then you MUST unpack a FileOpenResult if you want to get at the 
FileHandle (structural pattern matching makes that easy and fun, which 
is why it's important to add as well).

But, ah well, Java isn't going to get that it seems.

> It is interesting that when Java was hot circa 2000 many people believed
> that checked exceptions made sense.

Heh. I thought it made sense, myself. Under the premise of "well, if 
it's used correctly".
Except I never found a situation where a checked exception would have 
been useful, except for the kind of abuse you mentioned.

 > It is only relatively recently that
> people started to think differently.  There needs to be a compiler option
> to ignore them, but that will never happen.

Cannot happen, it would break backwards compatibility (your code would 
not compile in an environment where that option isn't set).
I routinely wrap checked-exception APIs in a thin layer that wraps each 
exception in a RuntimeException (with the original exception embedded, 
for stack traces). It's a bit tedious but not too hard to do, and I tend 
to add some more logging and checking logic at that point anyway.

E.g. my JDBC layer consists of code like this:

   static public PreparedStatement prepare (
       Connection connection, String sql)
   {
     PreparedStatement result = null;
     try {
       logger.debug ("Enter: prepare({}, {})", connection, sql);
       try {
         result = connection.prepareStatement (
             sql, ResultSet.TYPE_FORWARD_ONLY);
       } catch (SQLException e) {
         throw new RuntimeException ("Error preparing: " + sql, e);
       }
     } finally {
       logger.debug ("Exit: prepare(...) -> {}", result);
     }
     return result;
   }

The real code is a bit more convoluted, because it adds a parameter for 
result set concurrency, maps the integer codes to a textual 
representation in the log, and deals with multi-line SQL to the extent I 
needed it.

 > SimpleOrm never had checked exceptions.

I was talking on the posited assumption that somebody writes their own 
JDBC layer. I didn't intend to state anything about SimpleORM :-)

Regards,
Jo



------------------------------------
Posted by: Joachim Durchholz <[email protected]>
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/