Announcement Announcement Module
Collapse
No announcement yet.
Why foundOne doesn't throw an EmptyResultDataAccessException Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why foundOne doesn't throw an EmptyResultDataAccessException

    Hi I wonder why the method findOne doesn't throw an NoResultException or EmptyResultDataAccessException. I find it much more natural if I start searching with an Id.
    Is it possible to change the behavior and how? Ok one approach could be an Proxy which check if the Result is null an throw than an exception, but this sounds wired to me. Furthermore it would be interesting to know the drawbacks if I throw an exception.

  • #2
    Not sure what the reasoning is the only thing I can think of is that JPA also doesn't throw an exception when searching with an ID it simply returns null so it basically follows the specification here. Also handling these cases with an exception is imho a bad practice (you shouldn't use exceptions for your business flow but that is just me).

    You could create your own custom implementation or write and aspect that wraps around the findOne method...

    Comment


    • #3
      Well a DAO/Repository should be more than JPA, furthermore JPA throws an exception (NoResultException for getSingleResult).

      Handling business flow with exception is indeed a bad practice. But here we don't talk about something like a unique customnumber, we talk about a technical-id. So it's no user input, I will get it directly from an entity. I only know some few cases where you can handle such a situation gracefully.

      How ever I'm not deep enough in the framework, so that I know it will not have bad side effects, for example for conversion.

      Comment


      • #4
        Well a DAO/Repository should be more than JPA, furthermore JPA throws an exception (NoResultException for getSingleResult).
        Not when using find on the EntityManager it doesn't it does when using a Query but that isn't what is used underneath... And as mentioned throwing an exception is IMHO a bad practice regardless of what underlying technology one uses.

        Handling business flow with exception is indeed a bad practice. But here we don't talk about something like a unique customnumber, we talk about a technical-id. So it's no user input, I will get it directly from an entity. I only know some few cases where you can handle such a situation gracefully.
        In a perfect world... I have seen too many cases/projects where the customnumber or whatever is also used as technical-id.

        But that is probably a discussion which can take up a couple of threads .

        Comment

        Working...
        X