Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Before proceeding any further, please take a careful look at:</p> <blockquote> <p>The following are some of the generally accepted principles of exception handling:</p> <ol> <li>If you can't handle an exception, don't catch it.</li> <li>If you catch an exception, don't swallow it.</li> <li>Catch an exception as close as possible to its source.</li> <li>Log an exception where you catch it, unless you plan to rethrow it.</li> <li>Structure your methods according to how fine-grained your exception handling must be.</li> <li>Use as many typed exceptions as you need, particularly for application exceptions.</li> </ol> <p>Point 1 is obviously in conflict with Point 3. The practical solution is a trade-off >?between how close to the source you catch an exception and how far you let it fall before you've completely lost the intent or content of the original exception. </p> <p><a href="http://www.ibm.com/developerworks/java/library/j-ejbexcept/index.html" rel="nofollow">IBM DeveloperWorks: EJB best practices</a></p> </blockquote> <p>It is usually advised that you use checked exceptions for application exceptions at the business tier. I prefer to follow the business interface pattern to decouple the business tier from the user interface and web tier. This will allow me to think of your business tier as a service layer library and callers might want to handle different situations differently when calling this layer. That is one reason you might want to include checked exceptions, since you can react differently to different exceptions. Furthermore, including checked exceptions will usually help the caller code to be better aware of what different situations might arise from invoking some functionality. It could be worth it to take a look at the business delegate pattern and how it might help you with exception handling. In short, the <a href="http://www.ibm.com/developerworks/java/library/j-ejb1022/index.html" rel="nofollow">business delegate pattern</a> allows you to create a very thin layer between the business layer and the web layer where you can do things like exception handling.</p> <p>No matter how you go about doing this, make sure that you understand the implication of adding an application exception to your Java EE application. You may need to investigate how it interacts with your transaction management logic, specifically when it comes to transaction rollbacks. In my line of work, I had to add an @ApplicationException(rollback=false) to forbid the transaction manager from rolling back my transaction when an exception is thrown and propagated upwards.</p> <p>You may be able to tell I was working with EJB, but the concepts are probably very applicable to your design as well.</p> <p><strong>So back to your questions:</strong></p> <blockquote> <p>Is it necessary to log exceptions in the business tier?</p> </blockquote> <p>It is not necessary if you plan to log it later on. You better devise a logging strategy at a high level and log all caught exceptions there.</p> <blockquote> <p>If not, do I need to log exceptions at all (especially unchecked ones)?</p> </blockquote> <p>I think that you should log exceptions because that will help you debug any issues later on. The user is usually not savvy enough to capture any output that might be produced if the exception propagates and gets printed on his/her screen without you handling it.</p> <blockquote> <p>What happens to uncaught exceptions that are not logged using log4j? (If they're still printed in the console, what's the purpose of log4j?)</p> </blockquote> <p>I think it will eventually be caught by the web container and be printed out to the console. If an exception propagates upwards and reaches the web container exception handling safety nets, your exception is out of control. It is usually a sign of bad design. It is best if you keep your exceptions under control. Why wonder how a container will react to an uncaught exception? Also how beneficial will that exception be to the user? I think the information presented from uncaught exceptions are almost useless, as they are so far from the source of the error, that they become irrelevant and hard to work with when debugging.</p>
    singulars
    1. This table or related slice is empty.
    1. POBetter understanding exceptions and logging in a J2EE environment
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USZaki Saadeh
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POBetter understanding exceptions and logging in a J2EE environment
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

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