Project

General

Profile

Optimization #3160

clean up error codes

Added by Victor Julien 9 months ago. Updated 4 months ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

The list of error codes defined in util-error.h is massive and often not very helpful. One of the original ideas was to have a list of unique codes, but that hasn't materialized. The codes are often reused, lots are redundant and some may be unused.

Also, the codes often don't add all that much to the per error/warning custom message.

Consider a much simpler scheme. E.g. something like the errno approach (or perhaps exactly this).

#1

Updated by Jason Ish 8 months ago

By the errno approach are you referring to a more limited set of error codes? Or something functional like a thread local error variable as well?

#2

Updated by Victor Julien 8 months ago

Was thinking about a limited set of codes (EINVAL, ENOMEM, ENOENT, etc). But it would be good to consider how these errors would be passed along too.

#3

Updated by Jason Ish 4 months ago

Have been thinking about this one recently, so some points of discussion.

Do you have find that having the error code in the log message is very useful at all? I don't find it that useful, and its not something you see in most modern software systems (outside stuff like Microsoft, or Cisco where they do have a unique code for each error across the entire system). The other thing to consider is that SCLogWarn requires a code, where I don't think it always makes sense to have one.

But a set of error codes does make sense for passing things around to keep some context. This way we can avoid logging where the error occurred, and pass back an error code (would return values < 0 work for this)? In Rust it is idiomatic to use an enum of possible failures with the result type, so we could have a pretty close usage pattern.

I'd also like to suggest forgetting about the stability of the error code number? Does anything depend on this? It would be very nice if we could have our set of codes alphabetized, and not worry about their action value (or in Rust, where idiomatically they wouldn't have an integer value - but we can give them one).

Also available in: Atom PDF