FWIW, I use the word obtain in such contexts.
A naming pattern of mine is therefore:
create_something
just to create something
get_something
to get something
obtain_something
to get something anyway (i.e. creating it if it doesn't exist)
Sted
David Abrahams [EMAIL
From: William E. Kempf [EMAIL PROTECTED]
David Abrahams said:
William E. Kempf [EMAIL PROTECTED] writes:
People said they wanted it, and the cost is low (one int). I think
Greg is right that they wanted to attempt system-dependent recovery.
Well, I can agree that the cost is low...
From: David Abrahams [EMAIL PROTECTED]
William E. Kempf [EMAIL PROTECTED] writes:
That's a good idea. So would users prefer new exception types here,
or should I use the std:: exceptions?
IMO, it's always safer to use an exception type which provides
more-specific information.
From: Peter Dimov [EMAIL PROTECTED]
I don't see any drawback in throwing something derived from
std::runtime_error, and not std::runtime_error itself. This lets you
provide
more information for clients that catch(thread_error) and still lets
others
catch(std::runtime_error).
As for the extra
