StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
3542113
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
2010-08-22T15:50:45.643
CreationDate
2010-08-22T15:50:45.643
FavoriteCount
0
LastActivityDate
2010-08-22T15:50:45.643
LastEditDate
LastEditorUserId
0
OwnerUserId
13165
ParentId
3542058
PostTypeId
2
Score
11
ViewCount
0
LastEditorDisplayName
text
Body
I generally prefer exceptions if you're indicating an error of some kind. Otherwise you have to spend much more time sprinkling error handling code at different levels of your codebase rather than centralising the error handling in appropriate layers of the system - amongst other reasons. You may find this <a href="http://www.perlmonks.org/?node_id=230799" rel="nofollow noreferrer">old thread on perlmonks</a> a useful read. I'll reproduce my comment there below - since I mostly agree with what I wrote back then :-) <hr> Some reasons I like exceptions: <ul> <li>Robustness. I can forget to check for an returned error value. I cannot forget to check for an exception.</li> <li>Brevity. I prefer: <pre><code>$o->foo->bar->fribble->ni </code></pre> to <pre><code>$o->foo or return(ERROR_FOO); $o->bar or return(ERROR_BAR); $o->fribble or return(ERROR_FRIBBLE); $o->ni or return(ERROR_NI); </code></pre></li> <li>Clarity. With exception based code the "normal" flow of control is more explicit because it is not obscured by error handling code. I think that the first of the two code examples above shows the intent of the code more directly than the second does.</li> <li>Separation of concerns. The error condition and the error handler are different ideas. <ul> <li>You may want an error to be handled in different ways depending on the context.</li> <li>You may also not know how the error should be handled at the point it occurs.</li> <li>You may not know how the error should be handled at the time you write the code.</li> </ul> With the return-error-code style you end up having to either: <ul> <li>propogate error conditions to where the decision on how they should be handled can be made.</li> <li>propogating error handlers down to where the errors may occur</li> </ul> Both options rapidly become messy if there are many levels of code between the error condition and the error handler.</li> <li>No confusion between return values and error conditions.</li> </ul> There are probably some more ;-)
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POShould a Perl module raise exceptions (die/croak)?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USadrianh
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POShould a Perl module raise exceptions (die/croak)?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
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.