Re: how can I return a 'null' smart pointer?

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.