using try/catch as control mechansim, is it a good thing ?

[mast2as]

I have posted a few messages in the last few days about a project I am
working on which is a quite simple parser. I ended up using the try/
catch structure as a general mechanism to control what's happening in
the program when it finds a syntax error in the file it parses. I
would like to know if this is 'an acceptable thing to do' from a
programmation point of view, or if I should keep using it only for
catch exception created withing the program.

For example i do things like that for now

// if syntax error in the parsed file
void ParseFile()
{
...
throw( "syntax error in the file at line 23, in test.dat" )
...
}

try
{
ParseFile()
}
catch( const char *msg )
{
std::cerr << msg << std::endl;
}

Thank you -mark

[Ian Collins]

ma*****@yahoo.c om wrote:

I have posted a few messages in the last few days about a project I am
working on which is a quite simple parser. I ended up using the try/
catch structure as a general mechanism to control what's happening in
the program when it finds a syntax error in the file it parses. I
would like to know if this is 'an acceptable thing to do' from a
programmation point of view, or if I should keep using it only for
catch exception created withing the program.

For example i do things like that for now

// if syntax error in the parsed file
void ParseFile()
{
...
throw( "syntax error in the file at line 23, in test.dat" )
...
}

try
{
ParseFile()
}
catch( const char *msg )
{
std::cerr << msg << std::endl;
}

The subject line was a bit misleading, you aren't using exceptions as a
control mechanism, which is a bad thing, you are using then to catch an
exceptional condition, which is a good thing.

--
Ian Collins.

[mast2as]

>

The subject line was a bit misleading, you aren't using exceptions as a
control mechanism, which is a bad thing, you are using then to catch an
exceptional condition, which is a good thing.

Thank you Ian.
So even though the exceptional condition I catch is a syntax error in
the file which is getting parsed, this approach is still okay, is it ?
It is convenient for me because of course whenever an exception is
caught the memory is released poperly. So that's why i ended up using
it in that case.

[Ian Collins]

ma*****@yahoo.c om wrote:

>>The subject line was a bit misleading, you aren't using exceptions as a
control mechanism, which is a bad thing, you are using then to catch an
exceptional condition, which is a good thing.

Thank you Ian.
So even though the exceptional condition I catch is a syntax error in
the file which is getting parsed, this approach is still okay, is it ?
It is convenient for me because of course whenever an exception is
caught the memory is released poperly. So that's why i ended up using
it in that case.

Well that's the way I do it in my stock XML parser. A syntax error
isn't a normal occurrence, it is an exception that interrupts the normal
flow of parsing the document. The alternative is probably a lot of
conditional code to test for the error. I'd much rather assume the
document parses and throw if an error is encountered.

--
Ian Collins.

[Greg Herlihy]

On 3/4/07 3:44 PM, in article
11************* ********@t69g20 00...legro ups.com, "ma*****@yahoo. com"
<ma*****@yahoo. comwrote:

>>
The subject line was a bit misleading, you aren't using exceptions as a
control mechanism, which is a bad thing, you are using then to catch an
exceptional condition, which is a good thing.

Thank you Ian.
So even though the exceptional condition I catch is a syntax error in
the file which is getting parsed, this approach is still okay, is it ?
It is convenient for me because of course whenever an exception is
caught the memory is released poperly. So that's why i ended up using
it in that case.

Almost by definition, an "exceptiona l" condition is one that a program
cannot handle in the context of its current execution state. A parser that
encounters a syntax error while parsing is in exactly that situation. By
definition, input that a parser does not recognize is input that cannot be
handled in the execution state of the parser (otherwise, if the parser were
able to recognize the input then there would be no syntax error in the first
place - although a semantic error may be present).

Therefore, it is perfectly appropriate for a parser implemented in C++ to
throw an exception whenever it encounters any input that it fails to
recognize as grammatically correct.

Greg

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

On Mar 5, 6:44 am, "mast...@yahoo. com" <mast...@yahoo. comwrote:

The subject line was a bit misleading, you aren't using exceptions as a
control mechanism, which is a bad thing, you are using then to catch an
exceptional condition, which is a good thing.

Thank you Ian.
So even though the exceptional condition I catch is a syntax error in
the file which is getting parsed, this approach is still okay, is it ?
It is convenient for me because of course whenever an exception is
caught the memory is released poperly. So that's why i ended up using
it in that case.

I think it also depends no what you intend to do about it. If the
parser cannot continue or do anything useful then an exception is
probably fine. If it is going to try to complete the parse anyway (and
maybe try to flag other errors) then some other error handling
mechanism is probably more suitable.

Depending on what I'm parsing I may use either mechanism. If the text
to be parsed is generated by a user it is often better to try to
identify many errors at once (like your C++ compiler no doubt does).
If it is expected that the text is generated by a program then it is
entirely appropriate to stop on the first error (as XML parsers must).

Even if it would be convenient for your users to get more than one
error at a time this sometimes complicates the parser to such an
extent, and produces so many false errors that it may not be very
useful. You'll see this a lot in C++ parsers where the compiler can't
filter out secondary errors caused by an earlier problem.

I'd also say exceptions are fine for what you're doing. I use them
under these circumstances myself.
K

[adrian.hawryluk]

On Mar 5, 6:02 am, "Kirit Sælensminde" <kirit.saelensm [e-mail]>
wrote:

On Mar 5, 6:44 am, "mast...@yahoo. com" <mast...@yahoo. comwrote:

The subject line was a bit misleading, you aren't using exceptions asa
control mechanism, which is a bad thing, you are using then to catch an
exceptional condition, which is a good thing.

Thank you Ian.
So even though the exceptional condition I catch is a syntax error in
the file which is getting parsed, this approach is still okay, is it ?
It is convenient for me because of course whenever an exception is
caught the memory is released poperly. So that's why i ended up using
it in that case.

I think it also depends no what you intend to do about it. If the
parser cannot continue or do anything useful then an exception is
probably fine. If it is going to try to complete the parse anyway (and
maybe try to flag other errors) then some other error handling
mechanism is probably more suitable.

Depending on what I'm parsing I may use either mechanism. If the text
to be parsed is generated by a user it is often better to try to
identify many errors at once (like your C++ compiler no doubt does).
If it is expected that the text is generated by a program then it is
entirely appropriate to stop on the first error (as XML parsers must).

Even if it would be convenient for your users to get more than one
error at a time this sometimes complicates the parser to such an
extent, and produces so many false errors that it may not be very
useful. You'll see this a lot in C++ parsers where the compiler can't
filter out secondary errors caused by an earlier problem.

I'd also say exceptions are fine for what you're doing. I use them
under these circumstances myself.

K

These are great explanations. Please ignore my last post in this
thread. I didn't refresh my newsreader.

Thanks
Adrian