# How to make errors of zeek::protocol\_begin non fatal?

**URL:** <https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784>\
**Category:** Spicy\
**Created:** [May 19, 2025, 2:05pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784 "2025-05-19T14:05:16Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![hendrik](https://avatars.discourse-cdn.com/v4/letter/h/839c29/32.png) [@hendrik](https://community.zeek.org/u/hendrik)\
**Post date:** [May 19, 2025, 2:05pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/1 "2025-05-19T14:05:16Z")

</div>

I’m using zeek::protocol\_begin in a spicy parser to pass the payload to another analyzer (which I am also developing). This works well.  
However, the plugin only works if the other plugin is also loaded. So you can’t use it on its own.

What is particularly problematic for me, however, is that test cases with traces no longer work.

Is there an easy way to make an error of zeek::protocol\_begin not fatal?

---

<div class="post-metadata">

**Author:** ![Benjamin\_Bannier](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/benjamin_bannier/32/595_2.png) [@Benjamin\_Bannier](https://community.zeek.org/u/Benjamin_Bannier)\
**Post date:** [May 19, 2025, 3:37pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/2 "2025-05-19T15:37:33Z")

</div>

I assume you are using the [overload of `zeek::protocol_begin` with a child name](https://docs.zeek.org/en/master/devel/spicy/reference.html#spicy-protocol-begin) to forward to a particular named analyzer,

```auto
function zeek::protocol_begin(
    analyzer: optional<string>,
    protocol: spicy::Protocol = spicy::Protocol::TCP);

```

If your downstream analyzer supports DPD you could instead use the [overload forwarding into DPD](https://docs.zeek.org/en/master/devel/spicy/reference.html#spicy-protocol-begin-2) so a child analyzer is picked based on content.

```auto
function zeek::protocol_begin(protocol: spicy::Protocol = spicy::Protocol::TCP);

```

If the child analyzer does not support DPD (e.g., because you pass additional data to it in band like discsussed in [How to push status information from a spicy parser to an cpp parser?](https://community.zeek.org/t/how-to-push-status-information-from-a-spicy-parser-to-an-cpp-parser/7781)), you need to explicitly keep track whether the child analyzer is loaded. You could do that by querying that from the Zeek side and persisting the result, and then access that information from your Spicy code, e.g.,

```auto
# e.g., in your parent analyzer's `main.zeek`
const HAS_MY_CHILD_ANALYZER = Analyzer::has_tag("MY_CHILD_ANALYZER");

```

and then in your Spicy code

```auto
global HAS_MY_CHILD_ANALYZER = zeek::get_bool("HAS_MY_CHILD_ANALYZER"); # Semantically const.

...

zeek::protocol_begin(); # Adds DPD as a child analyzer.

...

# Guard at least the forwarding, maybe also the `protocol_begin`.
if (HAS_MY_CHILD_ANALYZER) {
    zeek::protocol_data_in(is_orig, $$); # Forward data to DPD.
}
```

---

<div class="post-metadata">

**Author:** ![hendrik](https://avatars.discourse-cdn.com/v4/letter/h/839c29/32.png) [@hendrik](https://community.zeek.org/u/hendrik)\
**Post date:** [May 19, 2025, 4:32pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/3 "2025-05-19T16:32:08Z")

</div>

I didn’t even think of combining zeek and spicy via get\_value. It works much better with your solution. But it still has a limitation: If the zeek script is not loaded, then get\_bool gives a fatal error. So there is no longer a dependency on the other analyzer, but on the zeek script within the same analyzer.

I therefore used johanna’s solution in the post [How to push status information from a spicy parser to an cpp parser?](https://community.zeek.org/t/how-to-push-status-information-from-a-spicy-parser-to-an-cpp-parser/7781) and added a very simple C++ function to the spicy parser that queries the analyzer\_mgr directly. Now there is no dependency on a zeek scripts anymore.

Nevertheless, your suggestion has helped me a lot. Thanks for that!

---

<div class="post-metadata">

**Author:** ![awelzel](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/awelzel/32/609_2.png) [@awelzel](https://community.zeek.org/u/awelzel)\
**Post date:** [May 19, 2025, 6:21pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/4 "2025-05-19T18:21:57Z")

</div>

> You could do that by querying that from the Zeek side and persisting the result, and then access that information from your Spicy code, e.g.,

Would `protocol_handle_get_or_create` not be an option? Are users able to handle the errors if the requested analyzer doesn’t exist?

[Controlling Zeek from Spicy](https://docs.zeek.org/en/master/devel/spicy/reference.html#controlling-zeek-from-spicy)

> This function will return an error if:  
> not called from a protocol analyzer, or  
> the requested child protocol analyzer is of unknown type or not support by the requested transport protocol, or  
> creation of a child analyzer of the requested type was prevented by a previous call of disable\_analyzer with prevent=T

---

<div class="post-metadata">

**Author:** ![hendrik](https://avatars.discourse-cdn.com/v4/letter/h/839c29/32.png) [@hendrik](https://community.zeek.org/u/hendrik)\
**Post date:** [May 19, 2025, 6:28pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/5 "2025-05-19T18:28:38Z")

</div>

I also thought at first that the function `protocol_handle_get_or_create` could be used. But it is the reason for the problem. In fact `begin_protocol` also calls it. The function creates the analyzer as follows:

```auto
auto child = analyzer_mgr->InstantiateAnalyzer(analyzer.c_str(), c->analyzer->Conn());
if ( ! child )
    throw ZeekError(::hilti::rt::fmt("unknown analyzer '%s' requested", analyzer));

```

---

<div class="post-metadata">

**Author:** ![awelzel](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/awelzel/32/609_2.png) [@awelzel](https://community.zeek.org/u/awelzel)\
**Post date:** [May 19, 2025, 7:04pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/6 "2025-05-19T19:04:46Z")

</div>

Ah, gotcha. Seems a `protocol_handle_try_get_or_create` returning an optional would be a good improvement, assuming this is a regular use-case. Neither writing C++, nor offloading to Zeek script seems great if the Spicy/Zeek integration technically has all that information.

Would you be up for creating a feature request at [GitHub - zeek/spicy: C++ parser generator for dissecting protocols & files.](http://github.com/zeek/spicy)?

---

<div class="post-metadata">

**Author:** ![hendrik](https://avatars.discourse-cdn.com/v4/letter/h/839c29/32.png) [@hendrik](https://community.zeek.org/u/hendrik)\
**Post date:** [May 20, 2025, 6:51am UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/7 "2025-05-20T06:51:00Z")

</div>

In fact, I would prefer it if there was a new function is\_analyzer\_available (or similar), which could then be used to protect the other functions (e.g. begin\_prococol). If you have no objections, I would submit a feature request tomorrow.

---

<div class="post-metadata">

**Author:** ![Benjamin\_Bannier](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/benjamin_bannier/32/595_2.png) [@Benjamin\_Bannier](https://community.zeek.org/u/Benjamin_Bannier)\
**Post date:** [May 20, 2025, 2:27pm UTC](https://community.zeek.org/t/how-to-make-errors-of-zeek-protocol-begin-non-fatal/7784/8 "2025-05-20T14:27:09Z")

</div>

Issues are always welcome, and there is no need to ask for permission!

I did create [Improve UX around forwarding to non-existing protocol analyzers from Spicy · Issue #4481 · zeek/zeek · GitHub](https://github.com/zeek/zeek/issues/4481) capturing both what you and @awelzel mentioned since they seem like worthwhile additions.
