Databases
StackOverflow2013
Postsdbo
POSimple CRUD operations Exception design
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POSimple CRUD operations Exception design
    primarykey
    data
    text
    <p>I am developing a very small test to simulate a 3 layered system so I can understand how Exceptions work. At the same time I would like to come up with a reasonable approach so I can use this design as further reference for similar operations in other applications.</p> <p>I have been reading through different articles on the topic and it seems that there is a huge controversy over using checked or unchecked exceptions which is making me doubt about my final design.</p> <p>I won’t go through the arguments used to criticize or support checked/unchecked exceptions because probably they are all well known but rather I will present my design looking for some advices in how to improve it and make it (as long as possible) similar to a real application. </p> <p>The system is in charge to perform basic CRUD operations in a relational DB (lets say MySQL) using JDBC. I have the following: a presentation layer, a service layer and a persistence layer. </p> <p>Based on this answer <a href="https://stackoverflow.com/questions/9256255/handling-dao-exceptions-in-service-layer">Handling Dao exceptions in service layer</a> it makes sense for me not to expose specific layer implemantation and decouple the layers. So I decided to create my custom exceptions and wrap them into a Base Exception per layer so I can translate specific layer exceptions (i.e SQLException) into general layer exceptions (i.e PersistentException, BusinessException). And if later on the implementation changes I can simply wrap the new one into the base exception expected by the higher layer. So I have the following exceptions:</p> <pre><code>com.user.persistent.exceptions |_ PersistentException |_ ExistingUserException |_ Some more.. com.user.business.exceptions |_ BusinessException |_ somemore.... </code></pre> <p>From Josh Bloch’s book Effective Java: <em>“Use checked exceptions for conditions from which the caller can reasonably be expected to recover.”</em> I am also not that sure but I believe a user can recover from a SQLExeption (i.e A user by mistake provides an existing ID, he can re-type the right one ) so I decided to make the previous exceptions checked exceptions. Here is an overview of how the classes look like:</p> <p>Persistence Layer.</p> <pre><code>public interface UserDAO { public void create(User team) throws PersistentException; } //Implementation in DefaultUserDAO.java @Override public void create(User team) throws PersistentException { try { System.out.println("Attempting to create an user - yikes the user already exists!"); throw new SQLIntegrityConstraintViolationException(); } catch(SQLIntegrityConstraintViolationException e) { throw new ExistingUserException(e); } catch (SQLException e) { throw new PersistentException(e); } finally { //close connection } } </code></pre> <p>Service Layer:</p> <pre><code>public interface UserService { void create(User user) throws BusinessException; } //Implementation of UserService @Override public void create(User user) throws BusinessException { System.out.println("Doing some business logic before persisting the user.."); try { userDao.create(user); } catch (PersistentException e) { throw new BusinessException(e); } } </code></pre> <p>Presentation</p> <pre><code> try { userService.create(user); } catch (BusinessException e) { e.printStackTrace(); } </code></pre> <p>Now the following points make me feel unsure about this design.</p> <ol> <li>I like the idea of having the compiler verifying if clients of the method catch/throw the declared exceptions when using checked exceptions. However, at the same time I think this approach leads to clutter code to handle all the exceptions. Not sure if it is because I am not making proper usage of exceptions or because checked exceptions really lead to clutter code.</li> <li>I also like the idea of decoupling layers by wrapping specific layer exceptions into General ones. But, I can see a lot of new classes being created for every possible exception instead of just throwing an existing java exception.</li> <li>I can also see that a lot the existing code on this application is devoted to handle exceptions and a small portion of it is devoted to the actual objective of the system.</li> </ol> <p>These are actually my main concerns and make me wonder if this is really a good design. I would like to hear your opinions about it (and perhaps some small snippets of sample code). Can you guys give me some hints on how can I possibly improve it? In a way I can achieve decoupling between layers and avoid leaking layer specific concerns.. </p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USBartzilla
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POSimple CRUD operations Exception design
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POSimple CRUD operations Exception design
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POSimple CRUD operations Exception design
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI had similar question in my mind.in my opinion use custom exception(like ur business exception) when you want to keep all the system failure in some auditing tables in database. In EJB/RMI days, business service consumers where outside the system meaning applet client would be running in users local browser, that time developers did not want to expose runtime exception to client. so they shipped this custom exception so that appropriate message could be displayed, now mostly all layers reside in the same runtime environment, so dont have custom exception unless u have strong reason for it.
      singulars
      1. POSimple CRUD operations Exception design
      1. USChetan
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload