Tuesday, 24 June 2008

Throw null.

Eugene posed an interesting question about Alex' blog entry on why the following code does not require main method to throw throwable -
  public class Weird {  
    public static void main(String[] args) {  
      throw null;  
    }  
  }
The fact that it throws a NPE has been discussed on Alex' blog.
But the reason(or my hypothesis) why the compile dos not require you to add a Throwable to throws clause is as follows -
  1. The null reference can always be cast to any reference type.
  2. Checked Exceptions should be declared in the throws clause.
  3. RuntimeExceptions and Descendants are exempt from the above requirement(2)
  4. Rephrasing 2 and 3 as "if the type is not an instance of RuntimeException", which translates to the following code -
    if(!(type instanceof RuntimeException)) {
     //check throws clause for validity
    }else {
     //dont check.
    }
    
    and we can see that 'null' case would go to the else block.
Q.E.D. ? (you decide)
Posted by sid at 12:27 PM in Thoughts on Java/J2EE

Thursday, 12 June 2008

Dont put a lot in IN.

So in case people were wondering if application alerts are a good idea; heres a sybase database oddity/limitation/defect which we noticed via our alerting mechanism.

This defect was not discovered during development, slipped through QA and did not show itself in production for quite a few months. And then suddenly one day it showed up in the alerts (see below) -

[com.company.servlets.GenericServlet] request string--->http://service.company.com:8080/category/get_ante/attrs?null org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not execute query; uncategorizedSQLException for SQL [select this_.atom as atom4_0_, this_.dte_orig as dte2_4_0_, this_.dte_update as dte3_4_0_, this_.country_code as country4_4_0_, this_.ante as ante4_0_, this_.updated_by as updated6_4_0_ from category_ante_intl_atom this_ where this_.atom in (?, ?, ?, ?, ?, ?, ?, ...1024 of them !!)];

SQL state [ZZZZZ]; error code [404]; Too many ANDs or ORs in expression (limit 1024 per expression level). Try splitting query or limiting ANDs and ORs.

So anyone who has used hibernate ("Restrictions.in") or even plain sql with an IN clause should be careful if the method takes an unbounded list and puts them inside the IN clause. Infact anyone writing one of those innocent looking DAO method which takes in a list of ids and returns a bunch of Objects could be guilty of causing this if they are not careful.
This is one of those unobvious scaling bugs which people run into (a similar famous scaling bug is documented here - BinarySearch )
And one of the criticisms of hashCode is the return type int instead of a long (again related to scaling).

This defect (or 'limitation' if you want to be polite) exists in sybase 12.5 and has been corrected in more recent versions of sybase ase. Also in Oracle this limit is even less, around a 1000 ! see here --> Oracle forum link.
So for portability we might have to keep that in mind.

Technorati Tags:

Posted by sid at 10:30 AM in Thoughts on Java/J2EE
« June »
SunMonTueWedThuFriSat
1234567
891011121314
15161718192021
22232425262728
2930