As it currently stands a more serious std::logic_error exception can
be downgraded into a less serious std::runtime_error exception if an exception is thrown whilst evaluating the throw expression.
Why do you say logic_error is "more serious" than runtime_error?though,
Semantically that's not true, insofar as seriousness is not defined
by the library. I guess you mean that -- assuming they're used as
intended -- a logic error could have been avoided by the programmer,
whereas a runtime error could not. Depending on the situation,
either one can leave the user high and dry.
On Tue, 8 Mar 2016 06:31:12 CST
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
As it currently stands a more serious std::logic_error exception can
be downgraded into a less serious std::runtime_error exception if an
exception is thrown whilst evaluating the throw expression.
Could you be more specific, please? logic_error is mentioned in my
copy of the C++ only in section 19.2.1 (per the index), and I don't
find any mention of "downgrading". I also don't understand how it
*could* happen, since the compiler generates exception-handling
instructions, and the language per se doesn't define logic_error.
Why do you say logic_error is "more serious" than runtime_error?though,
Semantically that's not true, insofar as seriousness is not defined
by the library. I guess you mean that -- assuming they're used as
intended -- a logic error could have been avoided by the programmer,
whereas a runtime error could not. Depending on the situation,
either one can leave the user high and dry.
I also don't understand how it *could* happen, since the compiler
generates exception-handling instructions, and the language per se
doesn't define logic_error.
Typically when constructing an exception derived from
std::logic_error a std::string object is created for the exception
message which can cause std::bad_alloc (a std::runtime_error
exception) to be thrown replacing the originally intended exception.
From my point of view, if std::string triggers bad_alloc, you're hipdeep in alligators because your heap is corrupted. Likely is the
In general std::logic_error is more serious then std::runtime_errorprocess.
because you can often recover from a std::runtime_error but a std::logic_error exception is often a sign that something is seriously screwed and the only safe course of action is to terminate the
std::string object is created for the exception message which can
cause std::bad_alloc (a std::runtime_error exception) to be thrown
replacing the originally intended exception.
Oh, so you mean that the programmer may do something in handling the exception to convert logic_error to runtime_error. Sure.
"James K. Lowden" <jklowden@speakeasy.net> writes:
Oh, so you mean that the programmer may do something in handling the
exception to convert logic_error to runtime_error. Sure.
No, the problem is
throw std::logic_error("I've made a terrible mistake");
calls the constructor
std::logic_error(const std::string&);
which has to construct a string, which might throw std::bad_alloc
There is also a constructor
explicit logic_error(const char*);
which doesn't have to call a string constructor.
On 2016-03-15 15:45, Gareth Owen wrote:
"James K. Lowden" <jklowden@speakeasy.net> writes:
Oh, so you mean that the programmer may do something in handling the
exception to convert logic_error to runtime_error. Sure.
No, the problem is
throw std::logic_error("I've made a terrible mistake");
calls the constructor
std::logic_error(const std::string&);
which has to construct a string, which might throw std::bad_alloc
There is also a constructor
explicit logic_error(const char*);
which doesn't have to call a string constructor.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 438 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 242:57:22 |
| Calls: | 9,145 |
| Calls today: | 1 |
| Files: | 13,432 |
| D/L today: |
1 files (2,685K bytes) |
| Messages: | 6,039,842 |