Exception handling?

[mlt]

In the constructor of a class I run various test to check that the input
data is valid, else I throw an exception:

....
....
MyTest(
int const k
, int const h
, U const & u
, U const & v
, P const & c
)
{

int controlnum = c.size() * c[0].size();
int basisnum = (u() - k) * (v.size() - h);


if(k<= 0 || h<=0)
throw std::invalid_argument("k h must be greater than zero");

if(uknots.size() <= 0)
throw std::invalid_argument("u was empty");

if(vknots.size() <= 0)
throw std::invalid_argument("v was empty");

if(controls.size() <= 0)
throw std::invalid_argument("c was empty");
....
....
}

The first thing that needs to be done is to catch the exceptions so the
error messages gets printed to the user. But how do I make sure the right
message is printed, do I make some sort of exception switch?

 

[Alf P. Steinbach]

* mlt:

In the constructor of a class I run various test to check that the input
data is valid, else I throw an exception:

...
...
MyTest(
int const k
, int const h
, U const & u
, U const & v
, P const & c
)
{

int controlnum = c.size() * c[0].size();
int basisnum = (u() - k) * (v.size() - h);


if(k<= 0 || h<=0)
throw std::invalid_argument("k h must be greater than zero");

if(uknots.size() <= 0)
throw std::invalid_argument("u was empty");

if(vknots.size() <= 0)
throw std::invalid_argument("v was empty");

if(controls.size() <= 0)
throw std::invalid_argument("c was empty");
...
...
}

The first thing that needs to be done is to catch the exceptions so the
error messages gets printed to the user. But how do I make sure the
right message is printed, do I make some sort of exception switch?

In a small program made just for your own use you simply use the
std::exception::what() method.

But in a larger program it's generally *not a good idea* to transfer UI messages
in exceptions.

There are many reasons for that, including internationalization problems, and
that code that throws generally doesn't know anything about high level goals,
and that it would be in conflict with use of exceptions for programmers, and so on.

Ask yourself, what business has the user knowing about arguments to MyTest?

And by the way, for the specific tests above I'd use 'assert', not exceptions.


Cheers & hth.,

- Alf

 

[Noah Roberts]

* mlt:

In the constructor of a class I run various test to check that the
input data is valid, else I throw an exception:

...
...
MyTest(
int const k
, int const h
, U const & u
, U const & v
, P const & c
)
{

int controlnum = c.size() * c[0].size();
int basisnum = (u() - k) * (v.size() - h);


if(k<= 0 || h<=0)
throw std::invalid_argument("k h must be greater than zero");

if(uknots.size() <= 0)
throw std::invalid_argument("u was empty");

if(vknots.size() <= 0)
throw std::invalid_argument("v was empty");

if(controls.size() <= 0)
throw std::invalid_argument("c was empty");
...
...
}

The first thing that needs to be done is to catch the exceptions so
the error messages gets printed to the user. But how do I make sure
the right message is printed, do I make some sort of exception switch?

In a small program made just for your own use you simply use the
std::exception::what() method.

But in a larger program it's generally *not a good idea* to transfer UI
messages in exceptions.

There are many reasons for that, including internationalization
problems, and that code that throws generally doesn't know anything
about high level goals, and that it would be in conflict with use of
exceptions for programmers, and so on.

Ask yourself, what business has the user knowing about arguments to MyTest?

And by the way, for the specific tests above I'd use 'assert', not
exceptions.

We recently had this conversation at my office (assert vs. exceptions).
We've decided that exceptions are, in most cases, the correct way to
go. I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

So anything that is obviously a programmer error, such as providing zero
as a denominator in an equation, should still be excepted so that the
program can recover instead of crash...because bugs have a tendency to
make it into release.

Use of BOOST_THROW_EXCEPTION performs much of the same task that assert
does and can give you a message with line number, etc...

 

[Sana]

In the constructor of a class I run various test to check that the input
data is valid, else I throw an exception:

...
...
My Test(
          int const k
        , int const h
        , U const & u
        , U const & v
        , P const & c
        )
      {

    int controlnum = c.size() * c[0].size();
    int basisnum = (u() - k) * (v.size() - h);

        if(k<= 0 || h<=0)
          throw std::invalid_argument("k h must be greater than zero");

        if(uknots.size() <= 0)
          throw std::invalid_argument("u was empty");

        if(vknots.size() <= 0)
          throw std::invalid_argument("v was empty");

        if(controls.size() <= 0)
          throw std::invalid_argument("c was empty");
...
...
      }

The first thing that needs to be done is to catch the exceptions so the
error messages gets printed to the user. But how do I make sure the right
message is printed, do I make some sort of exception switch?

catch std::exception


try
{
MyTest test(/* parameters here */);

// stuff to do
}
catch (std::exception e)
{
std::cout << e.what() << std::endl;
}

 

[csaba.trucza]

We recently had this conversation at my office (assert vs. exceptions).

  We've decided that exceptions are, in most cases, the correct way to
go.  I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

You might find Herb Sutter's article "When and How to Use Exceptions"
in Dr. Dobbs Journal enlightening. I did.

You can read it here: http://www.ddj.com/cpp/184401836

Regards,
Trucza Csaba

 

[Tony]

We recently had this conversation at my office (assert vs. exceptions).
We've decided that exceptions are, in most cases, the correct way to
go. I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

"You might find Herb Sutter's article "When and How to Use Exceptions"
in Dr. Dobbs Journal enlightening. I did.

You can read it here: http://www.ddj.com/cpp/184401836".

That article is rather dated.

Tony

 

[Kai-Uwe Bux]

Noah Roberts wrote:

[snip]

We recently had this conversation at my office (assert vs. exceptions).
We've decided that exceptions are, in most cases, the correct way to
go. I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

So anything that is obviously a programmer error, such as providing zero
as a denominator in an equation, should still be excepted so that the
program can recover instead of crash...because bugs have a tendency to
make it into release.

I guess, a lot depends on what you mean by "recover". If I have a graphics
program and issue a command to run a certain filter on the picture, I would
be slightly puzzled but not outraged if a box popped up telling me

"Sorry, one of my programmers screwed up: the routine you called threw
an error. I decided to leave the picture as it is."

However, if my compiler stumbled across an internal error, decided
to 'recover' and still produce some object code on the off-chance that it
would be correct, I would be very unhappy. That might send me on a goose
chasse to hunt down a bug in my code where it really lies in the compiler.

I think, whenever there is a clear cut notion of correctness, I prefer the
program to abort over producing incorrect results. At least, I want the
possible error in the output to be clearly flagged.


Best

Kai-Uwe Bux

 

[Bart van Ingen Schenau]

We recently had this conversation at my office (assert vs. exceptions).
  We've decided that exceptions are, in most cases, the correct way to
go.  I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

So anything that is obviously a programmer error, such as providing zero
as a denominator in an equation, should still be excepted so that the
program can recover instead of crash...because bugs have a tendency to
make it into release.

On comp.lang.c++.moderated, there is a lengthy discussion ongoing
about this very topic, in the thread titled "We do not use C++
exceptions" (http://groups.google.com/group/comp.lang.c++.moderated/
browse_frm/thread/d7b0a5c663467471#)

Bart v Ingen Schenau

 

[Guest]

* mlt:

I hate that coding convention...

     {

   int controlnum = c.size() * c[0].size();
   int basisnum = (u() - k) * (v.size() - h);

       if(k<= 0 || h<=0)
         throw std::invalid_argument("k h must be greater than zero");

       if(uknots.size() <= 0)
         throw std::invalid_argument("u was empty");

       if(vknots.size() <= 0)
         throw std::invalid_argument("v was empty");

       if(controls.size() <= 0)
         throw std::invalid_argument("c was empty");
...
...
     }

The first thing that needs to be done is to catch the exceptions so the
error messages gets printed to the user. But how do I make sure the
right message is printed, do I make some sort of exception switch?

int main ()
{
try
{
getArgs (k, h, u, v, c);
Mytest (k, h, u, v, c);
}
catch (std::invalid_argument& e) // could catch std::exception
{
std::cerr << "invalid argument " << e.what() << std::endl;
return EXIT_FAILURE;
}

return EXIT_SUCCESS;
}

In a small program made just for your own use you simply use the
std::exception::what() method.

But in a larger program it's generally *not a good idea* to transfer UI messages
in exceptions.

There are many reasons for that, including internationalization problems, and
that code that throws generally doesn't know anything about high level goals,
and that it would be in conflict with use of exceptions for programmers, and so on.

what would you typically throw?

Ask yourself, what business has the user knowing about arguments to MyTest?

And by the way, for the specific tests above I'd use 'assert', not exceptions.

you don't know what the source of the arguments is.
This might be some long running server that's been handed
a bunch of parameters by a human user. assert() may not
be appropriate.

 

[Guest]

* mlt:

In the constructor of a class I run various test to check that the
input data is valid, else I throw an exception:
...
...
MyTest(
         int const k
       , int const h
       , U const & u
       , U const & v
       , P const & c
       )
     {
   int controlnum = c.size() * c[0].size();
   int basisnum = (u() - k) * (v.size() - h);
       if(k<= 0 || h<=0)
         throw std::invalid_argument("k h must be greater than zero");
       if(uknots.size() <= 0)
         throw std::invalid_argument("u was empty");
       if(vknots.size() <= 0)
         throw std::invalid_argument("v was empty");
       if(controls.size() <= 0)
         throw std::invalid_argument("c was empty");
...
...
     }
The first thing that needs to be done is to catch the exceptions so
the error messages gets printed to the user. But how do I make sure
the right message is printed, do I make some sort of exception switch?

In a small program made just for your own use you simply use the
std::exception::what() method.

But in a larger program it's generally *not a good idea* to transfer UI
messages in exceptions.

There are many reasons for that, including internationalization
problems, and that code that throws generally doesn't know anything
about high level goals, and that it would be in conflict with use of
exceptions for programmers, and so on.

Ask yourself, what business has the user knowing about arguments to MyTest?

And by the way, for the specific tests above I'd use 'assert', not
exceptions.

We recently had this conversation at my office (assert vs. exceptions).
  We've decided that exceptions are, in most cases, the correct way to
go.  I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

So anything that is obviously a programmer error, such as providing zero
as a denominator in an equation, should still be excepted so that the
program can recover instead of crash...because bugs have a tendency to
make it into release.

Use of BOOST_THROW_EXCEPTION performs much of the same task that assert
does and can give you a message with line number, etc...- Hide quoted text -

I have ASSERT_X() that throws an exception with file and line number.
You can then easily swap between assert and exception. I find assert
easier to debug because it abort()s without unwinding the stack

 

[Guest]

Noah Roberts wrote:

[snip]

We recently had this conversation at my office (assert vs. exceptions).
  We've decided that exceptions are, in most cases, the correct way to
go.  I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

So anything that is obviously a programmer error, such as providing zero
as a denominator in an equation, should still be excepted so that the
program can recover instead of crash...because bugs have a tendency to
make it into release.

I guess, a lot depends on what you mean by "recover". If I have a graphics
program and issue a command to run a certain filter on the picture, I would
be slightly puzzled but not outraged if a box popped up telling me

  "Sorry, one of my programmers screwed up: the routine you called threw
  an error. I decided to leave the picture as it is."

But perhaps...

"An internal error occurred in the program and it is unable
to continue. Would you like the save the file you are working on?"

....would be more acceptable?

I regularly use a program that does something like this
(actually it emails a bug report)

However, if my compiler stumbled across an internal error, decided
to 'recover' and still produce some object code on the off-chance that it
would be correct, I would be very unhappy. That might send me on a goose
chasse to hunt down a bug in my code where it really lies in the compiler..

I think, whenever there is a clear cut notion of correctness, I prefer the
program to abort over producing incorrect results. At least, I want the
possible error in the output to be clearly flagged.

I've worked on communications stuff where aborting is low down
on the list of acceptable behaviours. Usually try to abort the current
"transaction", report as much about the circumstances and continue.

I believe ATT used to run programs to fix their databases
and they achieved lots-of-9s up times.

 

[anon]

you don't know what the source of the arguments is.
This might be some long running server that's been handed
a bunch of parameters by a human user. assert() may not
be appropriate.

But if those parameters are calculated depending on parameters (in valid
range) by a human user, the assert might be very appropriate.

 

[Noah Roberts]

Noah Roberts wrote:

[snip]

We recently had this conversation at my office (assert vs. exceptions).
We've decided that exceptions are, in most cases, the correct way to
go. I used to be of the assert bent but couldn't make a valid argument
that did not assume we'd fix assert conditions before release.

So anything that is obviously a programmer error, such as providing zero
as a denominator in an equation, should still be excepted so that the
program can recover instead of crash...because bugs have a tendency to
make it into release.

I guess, a lot depends on what you mean by "recover". If I have a graphics
program and issue a command to run a certain filter on the picture, I would
be slightly puzzled but not outraged if a box popped up telling me

"Sorry, one of my programmers screwed up: the routine you called threw
an error. I decided to leave the picture as it is."

Well, not exactly what I had in mind, but sort of.

I think, whenever there is a clear cut notion of correctness, I prefer the
program to abort over producing incorrect results. At least, I want the
possible error in the output to be clearly flagged.

Right. Like in the particular case I am thinking of we have a drawing
system and a calculation system. The user draws their system and then
decides, at some point, to see how well it would work (pipe flow
simulation). If we get an exception in the engine (div by 0 for
instance) we can abort the calculations without simply having the
application disappear on the user. I'm sure they'll still be upset but
we can provide them with a lot more information than letting it
crash...and they can save their system.

 

[Noah Roberts]

"You might find Herb Sutter's article "When and How to Use Exceptions"
in Dr. Dobbs Journal enlightening. I did.

You can read it here: http://www.ddj.com/cpp/184401836".

That article is rather dated.

It also seems to be more about exception vs. return code. Sutter just
mentions as point of fact that programmer errors are asserted but
doesn't seem to explain in any detail. I didn't read the whole thing at
this point, I think I've read it before...at any rate, it doesn't seem
to speak to the same topic.

 

[Noah Roberts]

On comp.lang.c++.moderated, there is a lengthy discussion ongoing
about this very topic, in the thread titled "We do not use C++
exceptions" (http://groups.google.com/group/comp.lang.c++.moderated/
browse_frm/thread/d7b0a5c663467471#)

Heh, it seems some of them are lost in a discussion regarding the SRP
but don't understand it.

SRP doesn't say that this constructor taking an IP address as an
argument must leave checking IP input to the user of the class. It says
that it must somehow, perhaps by leaving it to the client, have someone
else do that check for it. It could easily call an IP checker. Best
bet is probably an IP object that has its own validator.

 

[Tony]

It also seems to be more about exception vs. return code. Sutter just
mentions as point of fact that programmer errors are asserted but doesn't
seem to explain in any detail. I didn't read the whole thing at this
point, I think I've read it before...at any rate, it doesn't seem to speak
to the same topic.

I pretty much agree with his statement about when to use assertions rather
than exceptions. At least he recognizes that they are different animals and
should have different scenarios of applicability.

Tony