Hi Botond, thanks for taking the time to respond.
I would have though, from my (very) cursory overview of the code, that the
most obvious way could be to model it as an exception.
The configuration tree could be modified to support something like a simple
try/catch
The driver for this, from my point of view, is that I don't want to risk
dropping a log due to a parse failure (whether that be due to a bug or
change-of-behaviour in the receiving [or sending] nxlog software, nxlog
configuration, or change in the originating software, or unexpected (or
malicious) content of the log. At its most basic, no $raw_event should be
lost/clobbered by a parse failure.
Here's my initial impression of what it might look like:
Exec \
try { \
somemodule->parse_csv(); \
} except { \
# here, $raw_event should have been what it was before parse_csv
failed (or perhaps before the 'try' statement.
log_warn("Parse error parsing $raw_event"); \
}
The following would still have to work, naturally, and be implicitly
wrapped in a try/catch as per the default behaviour.
Exec somemodule->parse_csv();
Or perhaps it would be better to synthesise a new log message [error
report] (that could be forwarded like any other non-debug internal log)
that contained a complete diagnostic of the error message. This would make
nxlog easier to support as well.
Just my small thought on the matter.
Cheers,
Cameron
--
Cameron Kerr <cameron.kerr...@gmail.com>
See my blog at http://distracted-it.blogspot.co.nz/ (previously
http://humbledown.org/)
Skype me on cameron.kerr.nz
On 19 August 2014 00:41, Botond Botyanszki <b...@nxlog.org> wrote:
> Hi Cameron,
>
> On Fri, 15 Aug 2014 13:38:54 +1200
> Cameron Kerr <cameron.kerr...@gmail.com> wrote:
>
> > What I would like is to be able to catch errors; the documentation makes
> to
> > mention (that I have seen) of how to go about this. It would be nice to
> be
> > able to instruct nxlog to log the IP address (if applicable) and complete
> > message state, for the error.
>
> The current error handling is not flexible enough, this would need a
> major overhaul to be able to operate in one of the following modes:
> * suppress error , nothing logged,
> * continue and log error,
> * abort evaluation and log error,
> Return codes would allow some of this to be coded manually at the cost of
> making the configuration a lot uglier.
>
> > Do parse_json, parse_csv etc. return a value, that can be checked? It
> would
> > be great if this could be documented.
>
> Currently these are procedures. Procedures don't return a value. We'd
> need to create a function for each of these that would return a status
> code. What would it return, an integer or simply a boolean? And what
> about the error message?
>
> Regards,
> Botond
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> nxlog-ce-users mailing list
> nxlog-ce-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users
>
------------------------------------------------------------------------------
_______________________________________________
nxlog-ce-users mailing list
nxlog-ce-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users
