> The only real difference between your code and mine is you have an
> outer-most try block that catches a general Exception (possibly
> NullPointerException)... your code is no more impervious to null-pointers
> than mine, because:
>
> Connection con = null;
> con = ds.getConnection();
>
> and
> Connection con = ds.getConnection();
>
> is exactly the same thing! (And like you correctly noted, I did
> the former
> to avoid the annoying varible-scope problem.)
Except the above should cause an Exception rather then return a null
pointer.
>
> Both ways of implementation will give one the same results; it's
> just up to
> the individual developer to determine if a SQL resource errors should be
> caught by an outer-most try block and handled explicitly, or implicitly
> ignored (close resource only if not null).
>
> And a minor note, you will need yet a third nested try-finally
> block in your
> code to close your ResultSet...
Actually I do not. See the JDBC 1.1 and 2.0 spec which denote that closing
the Statement object implicitly closes the ResultSet object.
> Hence one can argue that my code is
> "prettier" ;-) even if it requires 3 explicit conditional
> checkers. I think
> the best (prettiest and most optimized) pattern would be a combination of
> both of our implementations:
>
> try
> {
> Connection con = null;
> Statement stmt = null;
> ResultSet result = null;
> try
> {
> ...
> }
> finally
> {
> con.close();
> stmt.close();
> result.close();
> }
> }
> catch(Exception e)
> {
> ... handle possible NullPointerException as well as other
> exceptions
> }
>
> This pattern has only 2 try blocks (one nested in another) and no explicit
> null checkers!
True! But I still wouldnt define them equal to null pointers :) To each
our own.
Dave Wolf
Internet Applications Division
Sybase
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf
> Sent: Wednesday, September 13, 2000 11:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cursors Open problem with multiple insertions
>
>
> Gene,
>
> Let me share another design pattern or "template" for working with JDBC I
> much prefer.
>
> I have great concerns with designs like this where you "prototype" members
> as null pointers just to get around the compiler's scoping issue with a
> finally clause. Basically the compiler is telling you that your member is
> out of scope in the finally that you declared in the try and is hence not
> definately assinged. Many people get around this by setting the member to
> null. My problem is you have introduced a null pointer right into your
> code. Now to work around the danger of your null pointer, you have to add
> conditional logic to prevent accidentally touching this null pointer.
> Dangerous and error prone in my opinion.
>
> I would instead use a design like the below. It still uses a
> finally block,
> has no chance of an object not being definately assigned, and, has no
> intrinsic null pointers.
>
> Connection con;
> PreparedStatement pstmt;
>
> try
> {
> Context ctx = getInitialContext();
> DataSource ds = (DataSource) ctx.lookup(CACHE_NAME);
> con = ds.getConnection();
> try
> {
> pstmt = con.prepareStatement("SELECT id, balance FROM
> account WHERE id
> =?");
> pstmt.setInt(1, _id);
> try
> {
> ResultSet rs = pstmt.executeQuery();
> rs.next();
> _id = rs.getInt(1);
> _balance = rs.getFloat(2);
> }
> finally
> {
> pstmt.close();
> }
> }
> finally
> {
> con.close();
> }
> }
> catch(Exception e)
> {
> e.printStackTrace();
> throw new java.rmi.RemoteException();
> }
>
> The finallys although not all at the end, do indeed fire last (as per
> Goslings spec), and I now dont need null pointers.
>
> Whatcha think?
>
> Dave Wolf
> Internet Applications Division
> Sybase
>
>
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Gene Chuang
> > Sent: Wednesday, September 13, 2000 1:50 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Cursors Open problem with multiple insertions
> >
> >
> > Good call Ana; and the following "template" is how you should
> > implement all
> > your jdbc calls:
> >
> >
> > Connection conn = null;
> > PreparedStatement stmt = null;
> > ResultSet results = null;
> > try
> > {
> > conn = dataSource.getConnection();
> > stmt = conn.getPreparedStatement();
> > results = stmt.execute();
> > }
> > catch(SQLException se)
> > {
> > }
> > finally
> > {
> > if(results !=null) results.close();
> > if(stmt !=null) stmt.close();
> > if(conn !=null) conn.close();
> > }
> >
> > Gene Chuang
> > Teach the world... Join Kiko!
> > <http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang>
> >
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Bhattacharyya, Ana
> > Sent: Wednesday, September 13, 2000 9:20 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Cursors Open problem with multiple insertions
> >
> >
> > well this can happen if u are not closing ur ResultSet or
> > statement objects.
> > Do close them in the finally block of ur code.
> > HTH
> > Ana
> >
> > -----Original Message-----
> > From: Purushotham Das K [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 13, 2000 12:08 PM
> > To: [EMAIL PROTECTED]
> > Subject: Cursors Open problem with multiple insertions
> >
> >
> > Hi Folks
> >
> > I am getting the folllowing error ----> " Maximum Number
> > of Cursors
> > Opened"
> > I have written a session bean that is accessing an entity
> > bean. Iam
> > working on weblogic 5.1 on solaris server.
> > When I insert 13 or more rows into a table in a single call to
> > session bean, I get the above error. Everything's fine when I try
> > to insert
> > less number of records
> > Can somebody enlighten me on this error?
> >
> > Thanks in advance
> > Purush
> >
> > ==================================================================
> > =========
> > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
> > STATEMENT OF CONFIDENTIALITY. The information contained in this
> > electronic
> > message and any attachments to this message are intended for
> the exclusive
> > use of the addressee(s) and may contain confidential or privileged
> > information. If you are not the intended recipient, please notify
> > USPowerSolutions Corporation immediately at (617) 547-3800, or at
> > [EMAIL PROTECTED], and destroy all copies of this message and any
> > attachments.
> >
> > ==================================================================
> > =========
> > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> > ==================================================================
> > =========
> > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
