Error handling for policy parser

Hi,

I was wondering on how errors should be handled when parsing policy
script, esp. when parsing types (in my case enums).

Between Type.cc and parse.y it seem that three different strategies are
used:

a) The method / function from Type.cc returns a error indicator (int or
    such) and parse.y calls error().
b) The method / function from Type.cc calls Error(), which it
    inherited from BroObj()
c) The method / function from Type.cc calls error().

Which is the preferred way of reporting errors and/or are there reason
to use or not use a particular variant?

(BTW, this is for the enum type stuff. The method in question is only
called from parse.y to add element to the enum type. I kinda want to
avoid a), because it involves code replication)

cu
gregor

Also, should SetError() be used? (Which sets the type's tag to
TYPE_ERROR)??

hmmm, one difference between error() and BroObj::Error() is the location
that's reported in the error message. error() uses the current parser
location, BroObj::Error() uses the location were the object was created.

Normally BroObj::Error() would probably be fine to use, however, for
enum we can't. The location where the EnumType object is created is the
place of the type foo: enum {...} statement, which is not necessarily
were the error occurred, if the enum if later "redef'ed".
(I think EnumType is the only *type* that can be redefined).
More generally, I think that the "location" of an EnumType is
ill-defined if it is redef'ed.

So, I can't use b)

(Sorry for the many mails, just trying to understand how the policy
layer is implemented ....)

cu
Gregor

hmmm, one difference between error() and BroObj::Error() is the location
that's reported in the error message. error() uses the current parser
location, BroObj::Error() uses the location were the object was created.

IIRC, the convention is that you use BroObj::Error() if there's a clear
Type object with which to associate the error, and otherwise error().

So it sounds like error() is the right approach for you.

    Vern

Also, should SetError() be used? (Which sets the type's tag to
TYPE_ERROR)??

Generally, yes (again if you have a Type object to work with). This helps
diminish cascading error reports.

    Vern