[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