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...

D'oh! 
[ OK - I don't know who I which "Bruce" I was thinking of ]

>  >, 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.

I think that's what I said: "Embraced RAII everywhere". That means 
that every resource that you acquire/allocate gets wrapped in 
something that will automatically close/release/delete it when it 
goes out of scope.

This simplifies code for both the exceptional and non-exceptional case.

>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());
>   }
>}

I note that you're not handling failures of the "new Device (n)" call. 
[ or the "push_back", either ]

Of course anyone can make up examples where exceptions are good/bad, 
so I won't bore you with mine.

>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.

--

-- 
-- Marshall

Marshall Clow     Idio Software   <mailto:marshall <at> idio.com>

It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.