• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Finder Methods + null params

 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Any idea waht to expect if you pass a null as a param to a finder method ?
e.g Let's say finder expects a String
valid value in d.b = "az, co, ia"
If I pass "az" - it will return the requisite value
If I pass "xx" - Finder Exception
What if I pass null ?
Thanks,
akasmar.
 
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try it out and see what happens
I don't see any FinderExceptions that will be thrown if a null value is given. In fact, since the container handles all this, it should be able to handle a null value. I couldn't find anything in the spec that says that null values are forbidden. In fact, that would be a bad thing under most cases (too restrictive).
I would assume that the container can handle whatever you throw it.
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know the answer to this either, but I like Nathaniel's explanation. Just wanted to add that there is nothing about this on the exam. Basically, if it is not specifically addressed in the specification, then it won't be asked on the exam... so you don't have to know what *could* happen under circumstances where you don't do what you're supposed to.
So if the spec says that YOU MUST NOT DO XYZ then unless the spec ALSO says that if you DO you'll get an XYZ exception, then you do not need to test what might happen if you go ahead and do the forbidden thing Of course, you're always welcome to try the forbidden thing just for fun... or to see if you can bring your server to its knees. But even the reference implementation is not a useful indication of how a server will behave when you do something wrong, because unless the spec tells you what will happen, then all you know is how the RI handles that Bad Thing.
The hardest part of figuring out what's on the exam related to this is the exceptions that could be thrown, because they're discussed in several different places in the spec. I WISH that the spec put ALL the exception-related stuff in the exceptions chapter.
Maybe I'll post some kind of an exceptions summary here to talk about that. Good question that got me thinking, though. Thanks!
cheers,
Kathy
 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I'm gonna tell here is true for BEA's Weblogic application server (7.02) and I'm not sure other application servers do the same.
For instance, when you pass null to the findByPrimaryKey method of a local home interface (weblogic.ejb20.internal.EntityEJBLocalHome), an ObjectNotFoundException is thrown by the container with message "Primary key was null!"
For other finder methods, if the input parameters is null, the related EJB-QL expression that will use it may produce an unknown value as per EJB specification 2.0 �11.2.7.4
I hope this helps...
 
catch it before it slithers away! Oh wait, it's a tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic