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

Discussion in 'C++' started by mast2as@yahoo.com, Mar 4, 2007.

  1. Guest

    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
     
    , Mar 4, 2007
    #1
    1. Advertising

  2. Ian Collins Guest

    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.
     
    Ian Collins, Mar 4, 2007
    #2
    1. Advertising

  3. Guest

    >
    > 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.
     
    , Mar 4, 2007
    #3
  4. Ian Collins Guest

    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.
     
    Ian Collins, Mar 4, 2007
    #4
  5. Greg Herlihy Guest

    On 3/4/07 3:44 PM, in article
    , ""
    <> 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.


    Almost by definition, an "exceptional" 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
     
    Greg Herlihy, Mar 5, 2007
    #5
  6. On Mar 5, 6:44 am, "" <> 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.


    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
     
    =?iso-8859-1?q?Kirit_S=E6lensminde?=, Mar 5, 2007
    #6
  7. Guest

    On Mar 5, 6:02 am, "Kirit Sælensminde" <>
    wrote:
    > On Mar 5, 6:44 am, "" <> 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.

    >
    > 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
     
    , Mar 5, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bienwell
    Replies:
    4
    Views:
    3,852
    bienwell
    May 27, 2005
  2. judith
    Replies:
    16
    Views:
    1,064
    Chris Uppal
    Oct 16, 2006
  3. Calling WebService with using and try catch

    , Nov 19, 2005, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    135
  4. Zam
    Replies:
    1
    Views:
    242
    Mark Schupp
    Mar 14, 2005
  5. Victor Hooi
    Replies:
    6
    Views:
    104
    Neil Cerutti
    Nov 20, 2013
Loading...

Share This Page