Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The short answer is it depends!</p> <p>You should only ever handle an exception if you can do something useful with it. The 'something useful' again depends on what you are doing. You may want to log the details of the exception although this isn't really handling it and you should really re-throw the exception after logging in most circumstances. You may want to wrap the exception in some other (possibly custom) exception in order to add more information to the exception. As @mbeckish touches on, you may want to try to recover from the exception by retrying the operation for example - you should be careful not to retry forever however. Finally (excuse the pun) you may want to use a finally block to clean up any resources such as an open DB connection. What you choose to do with the exception will influence where you handle it. It is likely that there isn't a great deal of useful things that can be done with many exceptions other than to report to the user that an error has occurred in which case it would be more than acceptable to handle the exception in the UI layer and report the problem to the user (you should probably log the exception as well, further down your layers).</p> <p>When throwing exceptions yourself, you should only ever throw exceptions in 'exceptional'circumstances as there is a big overhead in throwing exceptions. In your example you suggest you may be thinking of throwing an exception if no records are updated by your operation. Is this really exceptional? A better thing to do in this situation would be to return the number of records updated - this may still be an error condition that needs to be reported to the user, but isn't exceptional like the command failing because the connecction to the DB has gone down.</p> <p><a href="http://www.c-sharpcorner.com/UploadFile/akrao/ExceptionManagement11142005020738AM/ExceptionManagement.aspx" rel="nofollow noreferrer">This</a> is a reasonable article on exception handling best practices.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhere should I handle the exceptions, in the BLL, DAL or PL?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USs1mm0t
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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. VTDownMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO>...and you should really re-throw the exception after logging in most circumstances I have to disagree with you there. Exception handling is an extremely expensive process and if you are doing things properly there should be very few cases in which you even have an exception thrown. When you start letting exceptions control the flow of your application you are opening yourself up for a lot of trouble. I would argue that you should NEVER re-throw an exception unless you have a VERY GOOD argument for doing so and even then the argument is probably not good enough.
      singulars
      1. PO
      1. USjoshlrogers
    2. COSorry @joshrogers, I have to disagree strongly with you there. Catching an exception, logging it and then doing nothing is just plain wrong! I guess you mean that you should then return an error code as in you suggest in your answer. Personally I don't like this pattern. Although I agree you shouldn't use exceptions to control flow, the hit that you may get re-throwing an exception in this instance doesn't seem to be a big deal as ultimately something has gone wrong with the application. It also IMHO leads to cleaner code as you don't have to check return codes everywhere.
      singulars
      1. PO
      1. USs1mm0t
    3. COWhat if I am logging my exceptions into some log source. e.g. If in one of a DAL method, I log my exception, and if that method is being called from several places in PL, how would the log convey the information that from where the exception occurred in the PL code ?
      singulars
      1. PO
      1. USteenup
 

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