Re: Handling error/status messages by interface to C++ programs


11.09.2009

Hi Guys,

This is interesting what you are saying, and I thank you for your
advices to my problem. But, as I am not so fluent in all these details
about how to design a compiler, please tell me where I can find
examples of the C++ code implementing the various concepts you are talking about.

For the time being, I feel convinced that designing some sort of polymorphic messenger classes for displaying the various messages
from my "compiler", in an interface-dependent way,
is a reasonable idea, and that using intensively
exceptions for managing the error detection is rather a bad idea.
However, I have to say I have seen a simple example of an object-oriented parser design in some book (unfortunately I forgot
the title; the author had a Polish-sounding name), where exceptions were
used and recommended as an elegant solution to the reaction to error detection in the source text.
In addition, I cannot completely avoid using exceptions in my
program. Without going too much into details, I can say that in order
to perform various partial tasks of my compiler, the compiler needs
to perform some kinds of numerical calculations on rational numbers
for which I am going to have a dedicated class. As the rational arithmetic operations may sporadically end up with problems such as "overflow", in such cases exceptions have to be thrown.
So, if my compiler cannot perform the above calculations,
it has to catch the exceptions and signal such operational errors
to the user.
One thing that I am not sure of, though, is whether in the case of
signalling errors by exceptions, it would be possible to design
a compiler which detects more than one error in a single pass?

Leslaw


On Thu, 10 Sep 2009, H. S. Lahman wrote:

Responding to Keighley...

Therefore using exception handling facilities to deal with normal
processing (e.g., detecting errors in the code being parsed) is not a
good idea.


Whilst Mr lahman is a far more experienced designer than I, I'd like
to
venture a contrary opinion. Parsers tend to end up deeply nested; when
things go wrong you pretty much want to give up and jump back "to the
top",
bearing with you what went wrong and where (source code line and
token).
This sounds very well suited to a non-local jump with parameters. In
other
words an exception.

My counter is that would be true if one were doing procedural or functional development. However, in an OO context one uses peer-to-peer collaboration rather than a hierarchical structure. So the "top" is just another object to which one directly sends a message to kick off processing for a production, syntax row, or whatever.

In practice, for a parser one is likely to have a special "handler" object that recovers from errors. It would trigger user notification and do recover housekeeping like reseting the current syntax row's token stack because one wants to continue parsing and detect any other errors w/o aborting. When a problem is detected a message announcing the problem and its context would be sent directly to that "handler" object. That "handler" object would understand the error condition and would know where to go to continue processing. So it would send a message directly to that point -- an object owning the kickoff responsibility -- when it was done with its recovery. That object where the processing will continue is the same "top" one would reach via procedurally climbing a hierarchical call stack.

<aside>
Parsers are usually not a good application of OO because they tend to be highly linear (token1 -> token2 -> token3 ->...) for a specific LALR1 language. IOW, it becomes natural to map the specific syntax into depth-first hierarchical processing that can be implemented trivially in a procedural language. So when one attempts an OO approach one ends up with something like the GoF Command pattern where all the heavy lifting for an entire syntax row is done in a single method. In effect one has just encapsulated the depth-first hierarchy within a single method.

OTOH, if one wants to design a single parser to process multiple languages using something like generic BNF specifications, then OO is a good choice because one can abstract the invariants of parsing itself in a generic fashion with objects like Syntax Table, Syntax Row, Production, Terminal, etc.. Then the specific syntax elements like keywords are abstracted into things like attribute values. So my comments above are based on this view. B-)
</aside>


--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html


*-----------------------------------------------------------------------*
| Dr. Leslaw Bieniasz, |
| Institute of Physical Chemistry of the Polish Academy of Sciences, |
| Department of Complex Systems and Chemical Processing of Information |
| ul. Niezapominajek 8, 30-239 Cracow, Poland. |
| tel. (room) +48 (12) 6395212 tel./fax. (secretariat) +48 (12) 4251923 |
| E-mail: nbbienia@xxxxxxxxxxxxx |
| and Institute of Teleinformatics, Faculty of Electrical and Computer |
| Engineering, Cracow University of Technology, |
| ul. Warszawska 24, 31-155 Cracow, Poland. |
*-----------------------------------------------------------------------*
| Interested in Computational Electrochemistry? |
| Visit my web site: http://www.cyf-kr.edu.pl/~nbbienia |
*-----------------------------------------------------------------------*

.

Relevant Pages

  • Re: CASE...ENCASE Query...
    ... Once you've got one compiler and semantic checker, ... A 'syntax and semantic checker' designed ... for use at the 'compilation' stage will have very different design ...
    (comp.sys.acorn.programmer)
  • Re: Is Forth suitable for writing compilers?
    ... used to your syntax won't mind at all. ... need extra complexities in your compiler design too. ... Albert van der Horst, UTRECHT,THE NETHERLANDS ...
    (comp.lang.forth)
  • Re: How to test if an enum is inside a set
    ... > not how it is designed to be easy for the compiler ... compiler design. ... that delphi doesn't allow you to write something like this ... Perfectly valid syntax in C/C++. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Equals Operator
    ... Much of the syntax is taken from C/C++ design. ... compiler. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: why still use C?
    ... their associated method functions from a design perspective. ... to be at the mercy of the compiler and its designer, ... that uses all the available C++ features including exceptions and templates. ... good OOP programming, is just not for me (except for some obvious cases ...
    (comp.lang.c)