Boost logo

Boost Users :

From: gast128 (gast128_at_[hidden])
Date: 2008-07-17 06:19:02


Marshall Clow <marshall <at> idio.com> writes:

>
> gast128 <gast128 <at> hotmail.com> wrote:
>
> >Sutter has made a guideline for when to use exceptions and when not ("When
and
> >How to Use Exceptions", http://www.ddj.org/cpp/184401836). By using this
> >guideline, programmers actually have to deal with two strategies instead of
> >one, not to mention that writing excpetion safe code (without leaks) is very
> >hard. If you get stuck you can always buy his books :)
>
> Actually, having read all of Bruce's books
Eh, isn't his name Herb...

>, and having talked to him
> at a couple of conferences, I find that writing exception safe code
> is quite simple - once you have embraced RAII everywhere. You do have
> to think about exception safety, but for most routines that thinking
> boils down to "What happens if something throws here? Um, ....
> nothing bad.", since RAII ensures that no locals leak, and I can look
> at the global/parameter cases quickly.
Not sure about that. I think you probably have to wrap every raw pointer in a
smart pointer or ending up having try / catch everywhere. Writing everywhere
try / catch doesn't improve the readability imo (which is also depreciated by
people). Item 17-23 and item 29 of more exceptional c++ are all about case
where exceptions occur, none of them are trivial (for me at least).

> I find it also leads to simple, easy to write (and understand code).
Sure? What if you make a pool of available devices like (COM ports) and they
throw when not available (which btw raises the question if this an exceptional
case or just common):

std::vector<Device*> v;

for (int n = 0; n < nSize; ++n)
{
  try
  {
    Device* pDevice = new Device(n);
    v.push_back(pDevice);
  }
  catch (...)
  {
    //not available
  }
}

is this more readable then:

for (int n = 0; n < nSize; ++n)
{
  std::auto_ptr<Device> ptrDevice(new Device(n));
  if (ptrDevice->IsOk())
  {
     v.push_back(ptrDevice.Release());
  }
}

Probably I can predict your answer. If you write deep nested functions with
clear entry points, these exception can really improve the code, but then you
are using them as a pimped 'goto' statement, which was not the intention.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net