Re: Standard C++ file size ???
On Jul 8, 3:06 pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
On 7/8/2010 3:25 AM, James Kanze wrote:
On Jul 7, 5:36 pm, Peter Olcott<NoS...@OCR4Screen.com> wrote:
On 7/7/2010 11:10 AM, James Kanze wrote:
[...]
At least until the code is fully operational throwing non-text
exceptions makes the code substantially more complex than
necessary.
Just the opposite. Throwing exceptions of class type makes the
code substantially simpler than using a non-class type.
Making code substantially more complex than necessary
drastically increases development time, and reduces
reliability.
Which is why you shouldn't throw exceptions of text type.
I can't imagine needing to do anything besides reporting the
error and quitting for any of my code.
In which case, exceptions aren't really the appropriate
solution (except maybe throwing an int to force a termination
after having output the error). In most serious applications,
however, there are some types of errors which require particular
handling.
[...]
What are some examples of exceptions where recovery is possible?
Just about any exception in a server or a GUI based application.
In my current work, we use exceptions in various parsers. We
certainly don't want to abort the application (which would be
Excel, or the Java VM, or some other long running application,
since the code operates as a plug-in) just because the user
entered some incorrect expression.
Macros can be added to provide the file name and line
number of the error. I forgot what these are, do you
remember? This can even further simplify error detection
and correction.
__FILE__ and __LINE__.
The class type you throw generally does have a text element, so
you can insert these if necessary. Typically, however, I'd say
See what I mean by adding complexity? Text ALWAYS has a text
element, that is all that it has.
std::runtime_error doesn't have much more. Except for a type.
The type is critical.
that if they're useful, the error is one that should be handled
as an assertion failure, and not an exception. (And even in
assertion failure, their utility is questionable. How does it
help to know that your code failed in vector_impl.h, line 1234?
You really need a stack walkback.)
What is the criteria for determining those things most appropriate to
exception processing and assert failure processing? I would guess that
exceptions are best used when error recovery is possible. I can not
think of any instances of this.
Exceptions are for cases where recovery might be possible.
Things like bad_alloc (on a server, for example). They're also
appropriate in special cases of user error, like recursive
descent parsers, where you have to unwind the stack a lot (or an
indeterminate amount).
[...]
Recursive decent is neither as effcient nor as simple to
implement as a generated LALR parser.
That depends on the language, and the external requirements.
Generated LALR parsers are known for their poor error handling
(vague messages, poor recovery, etc.). They don't work well if
the language is too complicated---I wouldn't use bison to write
a C++ compiler. And they're largely overkill for very simple
languages. And the ones I know of also require textual input,
which makes them useless for parsing things like filter
expressions in BER encoded ASN.1.
--
James Kanze