Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Error codes vs. exceptions

Reply
Thread Tools

Error codes vs. exceptions

 
 
Luca Risolia
Guest
Posts: n/a
 
      05-29-2012
On 30/05/2012 01:01, Ian Collins wrote:
> Elegant maybe, but potentially very expensive if used injudiciously.


This is true. In that particular case, there might be much space for
compiler optimizations. It would be interesting to know how it performs
compared to a traditional recursive search.

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      05-29-2012
On 05/30/12 11:10 AM, Luca Risolia wrote:
> On 30/05/2012 01:01, Ian Collins wrote:
>> Elegant maybe, but potentially very expensive if used injudiciously.

>
> This is true. In that particular case, there might be much space for
> compiler optimizations. It would be interesting to know how it performs
> compared to a traditional recursive search.


Measurement would be the only way to know and there would probably be a
(probably large) data size beyond which throwing an exception would be
faster.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      05-29-2012
Luca Risolia wrote:

> What is elegant is a matter of opinion. Exceptions are not intended to
> handle errors only, not according to authors like Stroustrup at least,
> from whom I deliberately took one of the corner cases. Of course you
> have to consider every case *cum grano salis*, I did not mean to say
> that exceptions should always be used to control the program logic:
>
> "Using exceptions as alternate returns can be an elegant technique for
> terminating search functions – especially highly recursive search
> functions such as a lookup in a tree."
>
> from paragraph 14.5, "Exceptions that are not errors" ("The C++ Prog.
> Language" 3rd ed.)


If you continue reading that part, you will notice that it goes as follows:

«However, such use of exceptions can easily be overused and lead to obscure
code. Whenever reasonable, one should stick to the ''exception handling is
error handling'' view. When this is done, code is clearly separated into
two categories: ordinary code and error-handling code. This makes code more
comprehensible.»

Then, if you read the chapter as a whole, you will realize that the use of
exceptions as "simply another control structure" is depicted as an oddity
instead of a reasonable or even desireable application, and this sort of use
is far from being endorsed by the author. And the reason is quite straight-
forward; employing exceptions as control structures is a bit of a hack
which, although it might appear to be a clever trick, doesn't really do
anyone any good.


Rui Maciel
 
Reply With Quote
 
Luca Risolia
Guest
Posts: n/a
 
      05-29-2012
On 30/05/2012 01:23, Rui Maciel wrote:
> Luca Risolia wrote:
>
>> What is elegant is a matter of opinion. Exceptions are not intended to
>> handle errors only, not according to authors like Stroustrup at least,
>> from whom I deliberately took one of the corner cases. Of course you
>> have to consider every case *cum grano salis*, I did not mean to say
>> that exceptions should always be used to control the program logic:
>>
>> "Using exceptions as alternate returns can be an elegant technique for
>> terminating search functions – especially highly recursive search
>> functions such as a lookup in a tree."
>>
>> from paragraph 14.5, "Exceptions that are not errors" ("The C++ Prog.
>> Language" 3rd ed.)

>
> If you continue reading that part, you will notice that it goes as follows:


...which does not contradict what I said. I think we are saying the same
thing.
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      05-30-2012
On Mon, 28 May 2012 21:15:00 -0700, mike3 wrote:

> I've heard about this, and wonder when is it right to use codes, and
> when to use exceptions for reporting errors? I've heard various stuff,
> such as that exceptions should only be used to indicate "exceptional"
> conditions. Yet what does that mean?


It usually means that the condition will rarely occur in practice.

Performance-wise, exceptions are costly if the exception is actually
thrown but free if not thrown, while a status return has a constant
overhead. If the condition rarely occurs, exceptions will work out
cheaper; if the condition is common, returning a status will be cheaper.

But performance is seldom the main issue. If throwing an exception means
that typical code will just wrap the call in a try/catch block, you should
use a status return instead. If typical code will propagate errors up the
call stack, you should probably use an exception.

It's all about code structure. If exceptions make your code cleaner by
reducing the amount of error-handling code, use exceptions. If they just
mean that you replace if/else with try/catch, then use a status return.

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      05-30-2012
On 5/30/2012 9:23 AM, Nobody wrote:
> On Mon, 28 May 2012 21:15:00 -0700, mike3 wrote:
>
>> I've heard about this, and wonder when is it right to use codes, and
>> when to use exceptions for reporting errors? I've heard various stuff,
>> such as that exceptions should only be used to indicate "exceptional"
>> conditions. Yet what does that mean?

>
> It usually means that the condition will rarely occur in practice.
>
> Performance-wise, exceptions are costly if the exception is actually
> thrown but free if not thrown, while a status return has a constant
> overhead. If the condition rarely occurs, exceptions will work out
> cheaper; if the condition is common, returning a status will be cheaper.
>


pretty much.

a status code also has the advantage if the return value is used to
drive logic in the caller, such as knowing when a task has finished,
when a desired item has been found, ...


> But performance is seldom the main issue. If throwing an exception means
> that typical code will just wrap the call in a try/catch block, you should
> use a status return instead. If typical code will propagate errors up the
> call stack, you should probably use an exception.
>


agreed.

exceptions work much better for transferring control across multiple
levels of call frames.

if the handler logic is directly in the caller, then it is less convenient.


similarly, there may be the matter of seriousness:
if the situation is "serious" (as-in, could potentially compromise
correct functioning of the application), then an exception may make more
sense;
if the situation is something which could be reasonably ignored with
little or no consequence, then a status code may make more sense.


> It's all about code structure. If exceptions make your code cleaner by
> reducing the amount of error-handling code, use exceptions. If they just
> mean that you replace if/else with try/catch, then use a status return.
>


yep.

this is often what would happen in many cases, using a try/catch as a
slightly longer, and slower, alternative to an if/else block.
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      05-30-2012
On 5/29/2012 4:07 PM, Adam Skutt wrote:
> On May 29, 2:47 pm, BGB<(E-Mail Removed)> wrote:
>> On 5/29/2012 10:20 AM, Adam Skutt wrote:
>>> On May 29, 10:45 am, BGB<(E-Mail Removed)> wrote:
>>>> if you need to unwind the stack either way, then an exception may make
>>>> sense.

>>
>>> I fail to see how making the programmer manually do what the language
>>> does automatically is worthwhile. You're going to have to give
>>> examples, and if they're not relevant to general-case programming then
>>> please don't waste anyone's time.

>>


<snip rest>

I am not here to argue about nitpicking.

if the other posts in this thread are noted, the tradeoff depends on:
what one is doing in a given case;
which is more convenient in a given case.

try/catch is not always more convenient than if/else, and has tradeoffs
for when and where they might be used.


but, oh well, whatever...

relax, man.

 
Reply With Quote
 
Adam Skutt
Guest
Posts: n/a
 
      05-30-2012
On May 30, 10:40*am, BGB <(E-Mail Removed)> wrote:
> On 5/30/2012 9:23 AM, Nobody wrote:
>
> > On Mon, 28 May 2012 21:15:00 -0700, mike3 wrote:

>
> >> I've heard about this, and wonder when is it right to use codes, and
> >> when to use exceptions for reporting errors? I've heard various stuff,
> >> such as that exceptions should only be used to indicate "exceptional"
> >> conditions. Yet what does that mean?

>
> > It usually means that the condition will rarely occur in practice.

>
> > Performance-wise, exceptions are costly if the exception is actually
> > thrown but free if not thrown, while a status return has a constant
> > overhead. If the condition rarely occurs, exceptions will work out
> > cheaper; if the condition is common, returning a status will be cheaper..

>
> pretty much.
>
> a status code also has the advantage if the return value is used to
> drive logic in the caller, such as knowing when a task has finished,
> when a desired item has been found, ...
>


Or you just return the item and avoid the need for status altogether.
Success should be normally be implicit.

> > But performance is seldom the main issue. If throwing an exception means
> > that typical code will just wrap the call in a try/catch block, you should
> > use a status return instead. If typical code will propagate errors up the
> > call stack, you should probably use an exception.

>
> agreed.
>
> exceptions work much better for transferring control across multiple
> levels of call frames.
>
> if the handler logic is directly in the caller, then it is less convenient.


You've said this a whole bunch of times but never once demonstrated
how this is actually true. I can think of a few cases where it's
true, but they're all pretty contrived.

>
> similarly, there may be the matter of seriousness:
> if the situation is "serious" (as-in, could potentially compromise
> correct functioning of the application), then an exception may make more
> sense;
> if the situation is something which could be reasonably ignored with
> little or no consequence, then a status code may make more sense.
>


As I've explained to you before, it's normally impossible for the
function issuing the error to tell the difference between these two
situations. Again, you've never once demonstrated how to apply this
reasoning to writing correct, usable code.

Adam
 
Reply With Quote
 
Adam Skutt
Guest
Posts: n/a
 
      05-30-2012
On May 30, 10:23*am, Nobody <(E-Mail Removed)> wrote:
> On Mon, 28 May 2012 21:15:00 -0700, mike3 wrote:
> > I've heard about this, and wonder when is it right to use codes, and
> > when to use exceptions for reporting errors? I've heard various stuff,
> > such as that exceptions should only be used to indicate "exceptional"
> > conditions. Yet what does that mean?

>
> It usually means that the condition will rarely occur in practice.


I don't like this definition, personally. Yes, it is true that the
sort of events that typically cause exceptions are rare. However,
that fact doesn't do us much good when actually designing software.

> But performance is seldom the main issue. If throwing an exception means
> that typical code will just wrap the call in a try/catch block, you should
> use a status return instead.


No, what you should do is return an actual useful value to the
caller. It is enormously difficult for a function writer to
accurately predict where and how any given "exceptional" condition
will be handled, so this line of reasoning is rather dubious at best.
You're welcome to provide an example, though.

> It's all about code structure. If exceptions make your code cleaner by
> reducing the amount of error-handling code, use exceptions. If they just
> mean that you replace if/else with try/catch, then use a status return.


If you are replacing if/else with try/catch I'd likely argue that your
C++ code was most likely designed wrong in the first place.

Adam
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      05-30-2012
Luca Risolia wrote:

> ..which does not contradict what I said. I think we are saying the same
> thing.


I was pointing out that it is bad form to try to shoe-horn exceptions as
control structures, and therefore it isn't a good idea to depict this sort
of use as reasonable or acceptable, let alone elegant. As a control
structure, exceptions are like a rube goldberg machine, and it isn't a good
idea to advertise rube goldberg machines as something other than
entertaining gimicks. They may be cleverly built, they may work, but there
are plenty of alternatives which are far simpler, efficient and easier to
maintain.


Rui Maciel
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to use file I/o codes with form and controls codes Allen ASP .Net 1 12-03-2007 12:04 AM
Should I use exceptions instead of error codes? mike3 C++ 14 11-17-2007 10:04 PM
Virtual Key Codes, Scan Codes and ASCII Codes in C gj_williams2000@yahoo.co.uk C Programming 2 08-20-2005 11:04 AM
RegEx replace of html codes to ascii codes Greg -- ASP .Net 4 08-09-2005 07:27 PM
Exceptions vs. Error Codes Shane Groff C++ 8 10-10-2004 05:05 PM



Advertisments