StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
5119512
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
4
CommunityOwnedDate
CreationDate
2011-02-25T16:08:23.007
FavoriteCount
0
LastActivityDate
2011-05-31T08:02:07.017
LastEditDate
2011-05-31T08:02:07.017
LastEditorUserId
264697
OwnerUserId
264697
ParentId
5119304
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
I agree with the refactoring of Mahesh Velaga (+1 for that) and I like to add that logging errors at that level of the application is unusual. Especially when you decide to rethrow the exception any way. Therefore, I suggest that you remove the complete <code>try catch</code> with error logging and log only in the root of your application (if you're not already doing that). That makes your code much more cleaner. When you've done that, you'll see that what's left is a nice readable method with hardly anything else than business logic. UPDATE <blockquote> But if we do not put the 'try catch' in the datamodel layer, how would the main caller catch the error? i have been using this pattern for years.. please correct me if i am wrong. Refer to this <a href="http://www.codeproject.com/KB/architecture/three_tier_architecture.aspx" rel="nofollow">link</a>. </blockquote> Catching the way you do in your question or is done as is shown in the <a href="http://www.codeproject.com/KB/architecture/three_tier_architecture.aspx" rel="nofollow">referenced article</a> you provide is almost always sub optimal, because of several reasons: <ul> <li>Catching, logging and rethrowing at the service layer is unfortunate, because you will end up with double entries of this error in your logging system, simply, because you need to log at the top layer of your application anyway, because otherwise you will miss logging errors that do not originate from the service layer. Ignoring the error (by not rethrowing it) is also a bad idea, because the client should hardly ever continue when an error occurs.</li> <li>Catching at the presentation layer as shown in the <a href="http://www.codeproject.com/KB/architecture/three_tier_architecture.aspx" rel="nofollow">referenced article</a> is also unfortunate, because this way you don't log the errors, but more importantly, you present the user with possibly technical and obscure error messages (perhaps even in a foreign language) that they don't understand and it will frustrate them. Even worse, it could lead to information leakage that allows hackers to see what going on under the surface when attacking your application (in case of a publicly exposed web application).</li> </ul> This doesn't mean that you can't display any error information to the users, but only do that for exceptions that you thrown explicitly to present error information for the users. For instance: <pre><code>try { // Call into service layer } catch (BusinessLayerException ex) { this.ValidationSummary1.Add(new CustomValidator { ErrorMessage = ex.Message, IsValid = false }); } </code></pre> In this example, the <code>BusinessLayerException</code> is a special exception that is thrown from the business layer that contains error messages that are understandable for the user (possibly with a localized error message if your application is used by users of multiple languages). For all other exceptions, most of the time you don't want to show the user that exact error message, because you have no idea what went wrong and how severe the error is and what information the exception contains. The best thing to do is to have as less error handling logic as possible in your presentation layer, and handle this at one place in the top layer of the application. Here you ensure that an error page is displayed to the user in that case and you ensure that the error is logged to the logging system. You can <a href="http://www.asp.net/hosting/tutorials/displaying-a-custom-error-page-cs" rel="nofollow">configure</a> ASP.NET to show a custom error page in case of an error. Here's an example: <pre><code><customErrors mode="RemoteOnly" defaultRedirect="~/ErrorPage.htm"> </customErrors> </code></pre> The <code>ErrorPage.htm</code> can display general information like the general "it's our fault" error page here at Stackoverflow. Perhaps some contact information of support, your home phone number, so they can call you at night ;-) By implementing the <code>Application_Error</code> method in the global.asax, you can at a single place in the application log unhandled exceptions: <pre><code>void Application_Error(object sender, EventArgs e) { Exception ex = Server.GetLastError(); // Log the exception here. } </code></pre> Make sure you log al the information about the error you need, such as stack trace, error message, exception type, and all the inner exceptions that can occur. I hope this helps.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POsimplify my groupby
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USSteven
UserOwnerUserId
1. USSteven
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId

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.