tracee-ebpf: Error handling is hard from outside tracee class

[AlonZivony]

It seems that the tracee.handleError() method is the legitimate way to handle errors.
However, because it is a method of tracee it makes it hard to use in independent packages, which can have their own errors.
In my opinion we should aspire to divide the tracee package to more packages and this is one of the things holding us back.
I think a error handling class should be introduced and other classes will be given pointer to it.
What do you think?

[AlonZivony]

The current way to handle events outside of tracee is to use the config.ChanErrors but the errors will not be added to the error count.

[itaysk]

I'm not sure what you are suggesting instead, can you please elaborate?
Tracee holds stats about errors, that's why it is handling errors. If we split tracee to packages there's still going to be a place where tracee code calls package, and this is where the caller (which is tracee) can handle the error

[AlonZivony]

My point is that if tracee is divided to sub-packages we want to keep track of all the error.
It is impossible to do so if the interface for handling errors is a method of tracee.
In my opinion there should be a class to handle errors which can implement the stats information. All sub-packages will be able to use it and by that the errors count for example will update if sub-package has an error.
In the current conditions the only way to update the stats about error in sub-package is to return an error, which means that errors which are not fatal to the runtime won't be tracked.

[itaysk]

I'm not opposed to refactoring stats, just want to clarify your proposal and my response before we proceed:
say we took help() out of tracee. the code in tracee.Run() used to call help() internally and handle the error by calling tracee.handleError(). now it will call helper.Help() which returns an error. You are suggesting that helper.Help() will handle the stats of tracee directly. I propose that tracee.Run() will capture the returned error, and if it wants to call tracee.handleError() is can do so.
Is this correct?

[AlonZivony]

You are correct.
In my opinion it could be best practice that there will be a class containing the error channel handling and will export the stats.
I think printing the stats is the responsibility of printer class which can have access to it.