Re: throwable .vs. non throwable?
"James Kanze" <james.kanze@gmail.com> wrote in message
news:1185281925.224357.196390@m3g2000hsh.googlegroups.com...
On Jul 24, 3:39 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
[SNIP good replies]
Although I seem to recall something about there being a new,
and a new throwable.
That's a completely different issue. Normally, new notifies the
lack of memory by throwing std::bad_alloc. If the user wants to
get a null pointer instead, he can use a placement new with a
no_throw additional parameter, and new will return null, rather
than throwing, if there is not enough memory.
I think I'll take a look at the no_throw additional parameter, and attempt
to add it to StrmConvert. If that's the way placement new does it, then
maybe I should emulate it. Although it's most likely some enum or define,
I'd like to use something relatively standard.
Am I barking up the wrong tree, or is there a way to do what I
want?
My immediate reaction would be to avoid this sort of function to
begin with.
Well, this code was orignally designed for simple ouput without having to
build stringstream in my mainline.
I've since gone to using it for user input via sockets and there are many
times it is perfectly acceptable to allow default constructed values. In
fact, there hasn't been a case yet where it would cause my program to crash
if it wasn't. I parse out the fields and do any rudementary checking before
I pass them to StrmConvert. It is actually the rare occasion I want to know
if it didn't convert correctly (in fact, there hasn't been a case yet, but
I'm building for the future).
For other code I may work on in the future, I may want it to throw, which is
why I'm looking at the best way to do it.