[Bro-Dev] Error handling for policy parser

Gregor Maier gregor at icir.org
Fri Dec 10 14:20:56 PST 2010


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

On 12/10/10 13:10 , Gregor Maier wrote:
> 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


-- 
Gregor Maier                                             gregor at icir.org
Int. Computer Science Institute (ICSI)          gregor at icsi.berkeley.edu
1947 Center St., Ste. 600                    http://www.icir.org/gregor/
Berkeley, CA 94704
USA


More information about the bro-dev mailing list