StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
5611559
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2011-04-10T11:53:05.497
FavoriteCount
0
LastActivityDate
2011-04-10T11:53:05.497
LastEditDate
LastEditorUserId
0
OwnerUserId
147192
ParentId
5609503
PostTypeId
2
Score
12
ViewCount
0
LastEditorDisplayName
text
Body
As you can probably gather from the wealth of answers, there is certainly no consensus. Semantically, exceptions and error provide the exact same functionality. Indeed they are identical in about all semantic aspects, and errors can be arbitrarily enriched much like exceptions (you don't have to use a simple code, you can use a real bundle of data!). The only difference there is is their propagation methods: <ul> <li>errors have to be passed down manually</li> <li>exceptions are propagated automatically</li> </ul> On the other hand: <ul> <li>the possibility of an error is perfectly documented in the signature</li> <li>exceptions are silent on code inspection (read <a href="http://www.gotw.ca/gotw/020.htm" rel="noreferrer">GotW #20: Code Complexity</a> and cry) and hidden paths of execution make reasoning harder.</li> </ul> The very reason both solutions can appear clunky is simply that error checking is difficult. Indeed most of the code I am writing daily concerns error checking, whether technical or functional. So what to do ? Warning: demonstration ahead, jump over to the next section if you care only for an answer I personally like to leverage the type system here. The typical example is the pointer-reference dichotomy: a pointer is like a reference that can be null (and reseated, but it does not matter here) Therefore, instead of: <pre><code>// Exceptions specifications are better not used in C++ // Those here are just to indicate the presence of exceptions Object const& Container::search(Key const& key) const throw(NotFound); </code></pre> I will tend to write: <pre><code>Object const* Container::search(Key const& key) const; </code></pre> Or better yet, using clever pointers: <pre><code>Pointer<Object const> Container::search(Key const& key) const; template <typename O> O* Pointer<O>::operator->() const throw(Null); template <typename O> O& Pointer<O>::operator*() const throw(Null); </code></pre> Here I find the use of exception superfluous for 2 reasons: <ul> <li>If we are searching for an object, then there not finding it is both a perfectly common occurrence and there is not much data to carry about: cause of error ? it is not there</li> <li>The client does not necessarily consider it an error that it is not there, who am I to assume that I know her business better than she does ? Who am I to decide that there will never be a case where it won't be appropriate not to find what was asked for ?</li> </ul> I don't have a problem with exceptions per se, but they can make the code awkward, consider: <pre><code>void noExceptions(Container const& c) { Pointer<Object const> o = c.search("my-item"); if (!o) { o = c.search("my-other-item"); } if (!o) { return; } // nothing to be done // do something with o } </code></pre> And compare it with the "exception" case: <pre><code>void exceptions(Container const& c) { Object const* p = 0; try { p = &c.search("my-item"); } catch(NotFound const&) { try { p = &c.search("my-other-item"); } catch(NotFound const&) { return; // nothing to be done } } // do something with p } </code></pre> In this case, the use of exceptions does not seem appropriate :/ On the other hand: <pre><code>try { print() << "My cute little baby " << baby.name() << " weighs " << baby.weight(); } catch(Oupsie const&) { // deal } </code></pre> is certainly more appealing than: <pre><code>if (!print("My cute little baby ")) { /*deal*/ } if (!print(baby.name())) { /*deal*/ } if (!print(" weighs ")) { /*deal*/ } if (!print(baby.weight())) { /*deal*/ } </code></pre> <hr> What is the best then ? It depends. Like all engineering problem there is no silver bullet, it's all about concessions. So keep 2 things in mind: <ul> <li>Error reporting is part of the API</li> <li>APIs should be designed with ease of use in mind</li> </ul> If you find yourself wondering whether to use an exception or not, just try to use your API. If there is no clear cut winner, it is just that: there is no ideal solution. Oh, and do not hesitate to refactor your API when it becomes clear that the error reporting mechanism elected at the time of crafting it is no longer appropriate. Don't be ashamed: requirements change with time, so it is normal that the API change with them. Personally I tend to use exceptions for unrecoverable errors only: I therefore have few try/catch in my code, only in the outermost levels, to accurately log the error (love stack frames) and log a dump of the BOM as well. This is very similar (and indeed strongly influenced) by Haskell, the code there is seggregated in two clear cut parts: while any can throw exceptions, only the IO part (the extern one) may actually catch them. Therefore, the pure part must deal with error conditions with other ways in case they are "normal". If, however, I am faced with a problem where using an exception makes the code easier to read and more natural (which is subjective) then I use an exception :)
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIs there a general consensus in the C++ community on when exceptions should be used?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USMatthieu M.
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POIs there a general consensus in the C++ community on when exceptions should be used?
 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. COGreat answer. I like the bottom line: use whichever makes the code simpler. Enough of this meaningless *exceptions in exceptional cases* mantra.
 singulars
 PostPostId
 PO
 UserUserId
 USInverse
2. CO@Inverse: like many mantra, they are made to give a good rule of thumb to beginners :)
 singulars
 PostPostId
 PO
 UserUserId
 USMatthieu M.

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.