9

I am working on some software where the notion of a "less severe" error has now come up as a case to handle, and for logging purposes I want a term to use to represent these. The first to come to mind was "Soft Failure", as I am using "Failure" for the regular more-serious issues. If I do that, though, then it seems like I should rename the original to "Hard Error" by contrast. I'd really rather stick with single-word names, or at least have it be unrelated to the existing Success/Failure dichotomy.

I know this question might be a bit pedantic, but please forgive that as I'm a nut for properly naming things in a concise and descriptive way in my software (which any of you who program know is a good thing for anyone else who works with it).

Currently I'm leaning toward using "Fault", as it almost fits, but a better suggestion would be welcomed.

Edit: Since others seem to have a bit of the wrong idea of what I mean, let me clarify. The term would not be used to refer to a completely unexpected failure - that's what "Failure" is for in the system. This is for expected but rare events that aren't good but aren't a problem in the software. For example, you connect to a database and try to grab a value, but the connection times out due to latency. Another example could be that upon trying to get a value it is missing from the database entirely. Again, this isn't "broken", it's just a missing piece of data, but everything is operating properly. That makes things like "glitch" and "bug" feel ill-suited.

Improve this question
11
  • 2
    Then why not use error as opposed to failure? Error is routinely used to refer to entry (or lack of entry) in sytems, not just computing malfunction.
    – bib
    Commented Oct 14, 2016 at 12:19
  • Those errors you mention would be errors or exceptions; but recoverable. If you need to differentiate between them - I'd advice an error level or severity level instead of different name. So I'd keep the Error name.
    – Allan S. Hansen
    Commented Oct 14, 2016 at 12:19
  • @AllanS.Hansen Recoverable is an excellent modifier for this situation! "Recoverable Failure" is pretty clear in describing what I mean. I wish it were shorter or more concise, but barring a better idea I'd pick this as an answer if you post it. The reason for a different name is because these are used on a lookup table for the result of the event, and for filtering purposes I don't want to conflate unexpected failures with minor ones. Perhaps "Unexpected Failure" and "Recoverable Failure" would be a good separation. I suppose I could add a flag that delineates severity or "recoverability"..
    – Yushatak
    Commented Oct 14, 2016 at 12:22
  • 13
    The term "warning" is often used in this sense.
    – Hot Licks
    Commented Oct 14, 2016 at 12:46
  • 3
    This is another case where sticking to a convention is critical--other people seeing the code won't necessarily speak English or get subtle meanings. As suggested elsewhere, this is exactly what "warning" means in this context.
    – jimm101
    Commented Oct 14, 2016 at 13:33

8 Answers 8

Reset to default
36

Most users understand the distinction between Warning and Error

So, if the issue is fairly mild and recoverable, then you term this as a Warning and let the user have some way of rectifying the situation (if applicable).

If the situation isn't rectifiable, then you have at least warned the user that something is amiss.

This seems (at least to me) to be understandable and straight-forward (which what we typically want in program messages).

In logging, there's typically three severity levels:
1) Error - Something's gone wrong and can't be recovered
2) Warning - Something's gone wrong, but it's not too bad
3) Information - Nothing's gone wrong, but the event is logged for logging's sake (x process has started/finished etc.)

Improve this answer
10
  • 2
    This is exactly the intention of warning in logging, and is built into any logging system worth the name.
    – jimm101
    Commented Oct 14, 2016 at 13:32
  • 1
    This is a developer/admin-end part of the system, so the end users will see messages in this fashion when things occur. That said, you bring a valid point with sticking to the logging convention that is often used. The rationale behind the usage of Failure/Success is that we're dealing with a data service and so the "request" is failing or succeeding. Perhaps I was trying to shoehorn the notion of severity into the wrong place, though. Since I'm doing work on this part of the system anyway, I will refactor so that it has a separate severity with the standard terminology. Thank you!
    – Yushatak
    Commented Oct 14, 2016 at 14:17
  • 3
    In compilers, warnings are also often used to point to patterns that are at risk of introducing unexpected behavior, but which aren't themselves illegal according to the language specification. For example, in C, it is valid to write if (i = 1) { /* do something */ } but the effect of that is going to be very different from the likely intended if (i == 1) { /* do something */ }. For the non-programmers: C, and many languages that derive from C, use = for assignment and == for equality comparison. E.g. Pascal instead use := and =, respectively.
    – user
    Commented Oct 14, 2016 at 15:31
  • 3
    I disagree entirely with your definition of warning. generally, a warning is not used when something is wrong, but when a user has done something typically advised against, either because it is bad practice or could become deprecated in the future.
    – user163011
    Commented Oct 14, 2016 at 17:26
  • 2
    @theonlygusti Well, disagree all you want, but that's how the term is used in logging systems.
    – HopelessN00b
    Commented Oct 14, 2016 at 20:21
7

There's actually a lot of more-or-less standard terminology for this in various bug-tracking systems.

Cosmetic refers to an error that does not affect functionality, but rather is visual only. Examples include a mis-spelled word, a problem in alignment of two form fields, or inconsistent colors.

Blocking refers to an error that completely prevent some portion of the functionality from working: a form can't be submitted, a report contains no data, etc.

In between those two extremes, you can have intermediate fault levels such as "major" and "minor".

Improve this answer
1
  • This isn't a bug tracking system but an audit log for a live system, but the term "Blocking" is useful and I hadn't come across that one - the group I work with generally uses colloquialisms like "showstopper" for things like that. Thanks for the input.
    – Yushatak
    Commented Oct 14, 2016 at 12:19
7

Recoverable Error as a distinction from the severe errors / exceptions.

  1. a program error that can be corrected and does not cause the program to fail or irretrievably lose data.
Improve this answer
2
  • 1
    Interestingly, this is rather different to how Sun used the term in their high-end file system ZFS. There, a storage device can experience an unrecoverable error which is automatically corrected by using available redundant data. In that case, the "unrecoverable" part refers specifically to the physical storage, not the availability of the data as the user is likely primarily interested in. (Of course, if redundant data is not available, then an unrecoverable error can indeed result in loss of data.)
    – user
    Commented Oct 14, 2016 at 15:33
  • Within the industry - terms and labels are always redefined and used subjectively - because after all - it's language and words and not static definitions.
    – Allan S. Hansen
    Commented Oct 14, 2016 at 16:22
5

You want WARNING. This isn't really an ELL question - in computer land there is a well established hierarchy of errors you are expected to use. For application logging events should generally be categorized into

  • FATAL
  • ERROR
  • WARN
  • INFO
  • DEBUG
  • TRACE

Though in systems land e.g. syslog has a slightly variant list.

Under no circumstances should you be making up your own new names for error or log levels; existing standards for these things ensure understandability by the reader. Read "Logging Levels And How To Use Them" for more details.

If you need to name anything else in computer land, please look for existing domain resources and don't just hit the thesaurus. The next person to look at your code or its output will thank you.

Improve this answer
3

Another example could be that upon trying to get a value it is missing from the database entirely.

In my experience, that would be an error. It would have an error number and an accompanying error message. It might not be a critical error, but nevertheless an error.

In some systems, there are warnings in addition to errors. For example, the XSLT 2.0 specification states:

When the implementation makes the choice between signaling a dynamic error or recovering, it is not restricted in how it makes the choice; for example, it may provide options that can be set by the user. When an implementation chooses to recover from a dynamic error, it may also take other action, such as logging a warning message.

[Definition: A dynamic error that is not recoverable is referred to as a non-recoverable dynamic error. When a non-recoverable dynamic error occurs, the processor must signal the error, and the transformation fails.]

Improve this answer
1
  • 1
    For clarity (you're absolutely right in general), the specific situation I was alluding to is default values for fields being pulled from a particular table. It isn't critical that a default value get populated (the user can still select one), but if it's missing then the admin(s) should be able to see so in the log. I probably should have been more specific since a few people were bound to have the experience to know what I was on about.
    – Yushatak
    Commented Oct 14, 2016 at 14:22
2

Consider glitch

A minor malfunction, mishap, or technical problem; a snag:

a computer glitch; a navigational glitch; a glitch in the negotiations

American Heritage Dictionary

Improve this answer
1
  • 2
    This would be better suited to when the event is completely unexpected but minor - I'm talking about things that I expect to happen at some point but rarely, and that aren't good but aren't "broken". Thank you for the input, though.
    – Yushatak
    Commented Oct 14, 2016 at 12:13
2

I like the word quirk when you want to convey the notion of something that's a little unexpected but not overtly unwelcome (like an error or a failure).

Definition: http://www.merriam-webster.com/dictionary/quirk

Full Definition of quirk

b : a peculiar trait : idiosyncrasy c : accident, vagary

Consider also the word vagary, listed there as a synonym to quirk.

Improve this answer
1
  • 1
    Not quite the thing I was looking for, but it would be ever-so-amusing to see "Quirk" alerts in a log. If I end up in a situation where I could make that happen I definitely will, heh. I like the outside-the-box suggestions, which is part of the reason I asked here rather than StackOverflow or etc..
    – Yushatak
    Commented Oct 14, 2016 at 14:25
1

Hiccup, speedbump, sneeze, deviation, cock-up, bungle, botch, etc. etc... You could go on all day, and really confuse the daylights out of anybody using your system ("OMG we just had a Mess-Up With Extreme Prejudice!" "No, we're fine, it was just a Pratfall With Light Headwind!") but really, since you're "writing" (you're in this forum, right?) you have to ask yourself one key question: Who's the audience?

Since you say it's IT people, they are going to understand the warning/error paradigm -- they'd expect "File transfer succeeded with the following warnings:" or "Transfer failed with the following errors:" but never "Succeeded with errors". So there you go. Keep it simple, error vs warning, maybe have "levels" if you have to... don't go too crazy with it. IMO.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .