I have a question about naming of terminal states of a task regarding to computing area. Think of a task that is being processed by some system. There're several possible states the task can be ended up in.

I want to find short (one-worded if possible) and unambigous names for these particular states:

  1. When the task is finished with success, i.e. it's completely processed. Options: Succeeded, Successful, Completed, ???
  2. When the task is intentionally canceled by some external "will", e.g. by user or by another system. There's nothing erroneus in this state, because everything was ok during processning and intent to stop was conscious. I think Canceled is the only option.
  3. When the task is stopped because of reaching some invalid inner state (e.g. due to errors) which cannot be properly handled by processing system to continue the task. Options: Aborted/Faulted/???

There's an example of such naming scheme in Microsoft .Net Framework for Task objects - TaskStatus enumeration (look at Members part). According to it the states from the list above are: RanToCompletion, Canceled, Faulted.

But I'm confused with RanToCompletion option (whish corresponds to my 1st item). The description from linked page for both Faulted and RanToCompletion options says that "task completed" (either with errors or without respectively). Therefore I think that RanToCompletion option is kinda ambigous because it isn't clear how successful the "completion" is. Also it'd be better to use one word if possible.

The word Aborted as an option for 3rd list item seems ambigous too for me as I understand it as a generic term for 2nd and 3rd, i.e. task can be aborted by some external or internal event.

Thank you in advance!

  • 1
    Completed, Canceled, and Aborted will do the trick. The contrast between canceled and aborted shows the agent is human or the system. You may need more states than three. Commented Jul 10, 2017 at 13:35
  • You may need a state for Waiting-Suspended-Held. Commented Jul 10, 2017 at 13:49
  • This is more about User Experience than the use of English, so I think that's the right Stack Exchange site for it. Commented Jul 10, 2017 at 14:55
  • 1
    @YosefBaskin thanks for the answer! As for the additional state - I don't need it for my case but it's good for my general understanding.
    – pkuderov
    Commented Jul 11, 2017 at 12:11

1 Answer 1


I will go ahead and answer this because not only do I love words, but I'm also a 25 year long professional, nearly 32 years total, in the computer science field. My specialty in fact is in .Net :)

Completed or Successful: for the task is done, finished, accomplished it's work.

Cancelled: for intentional action by the user to stop the task or process.

Aborted: for some inner state or invalid condition which causes the task to halt or stop.

Failed: for some inner state or invalid condition which causes the task to "fail" (this is similar to "abort" but the semantic difference is that aborted indicates certain things might have succeeded and the process stopped, this example could mean a larger, more critical, type of "failure" which caused the entire operation to not succeed). Failed and Aborted will not always have meaning separately depending on the context of the processes involved.

Faulted: for when the task technically completes, meaning the process was able to finish, but it had errors.

As Yosef mentioned you also might want an option for when the system is "on hold" or waiting. Waiting or Suspended are both good options for that condition. I would not use "Held".

I think your confusion about "Faulted" and "RanToCompletion" is that you are thinking Faulted means successful in exactly the same way "Completed/Completion" does? Per the documentation at your link? What it means is that the process technically finished but there were errors. This is different than cancelled in that "cancel" is a process caused by user action. "Aborted" is a process caused by an internal failure which is unrelated to user action but caused the process to be unable to complete.

"Faulted" is a special condition where a process is capable of completing (not all processes will be able to do this - depends on the context of your API and what it's doing), and it did complete, but it completed with some errors. Again, it's still a "type" of failure; one that technically completed but had errors. Not all programming processes will be capable of this condition. For example "Save File". The file either saves or it doesn't. There are no intermediate steps or conditions or processes which would allow us to say the "Save" process completed but had some errors.

Edit: I want to edit my example regarding the "Save" process, per the comments section. I'll use a simpler example, because "Save" could actually have an internal failure but still complete (see comments). It's still a "Faulted" state but, again, not all processes will be capable of a "Faulted" state.

Processes which will be able to fault will typically be processes which have multiple things going on, are capable of completing "some" things, but not others, etc...

Let's not be overly pedantic about this please. I'm trying to display the difference in meaning to a non-native speaker. Yes, you could probably always find a way to say that there is an internal failure but the process technically "completed" in which case we would call it a "Fault". That's why I used "Save" originally. But I agree it's not the best example.

A better example: "Process.OpenFile". There are not many cases where we could imagine a "fault" like behavior. Yes, yes, you could come up with scenarios. But basically if the intended action is to open a file for use (ostensibly in a GUI) for a user, then it either open's (success) or it fails (doesn't open) for use by the user.

  • +1 for distinguishing between faulted and aborted. There is a difference between a program ending due to a detectable problem with its input data (e.g. 1 out of 1000 input stock symbols wasn't in the lookup table), and ending due to a problem that was not anticipated by the programmer (like trying to take the square root of number expected to be positive but not).
    – user205876
    Commented Jul 11, 2017 at 0:45
  • Oh my, thank you so much for the answer! This's exactly what I wanted to clear up in my mind :) So we ended up with 4 states: 2 for interrupted uncomplete tasks which are either canceled by outer cause or aborted by inner cause; and another 2 for the kinds of completion - it's either successful or faulted. Right?
    – pkuderov
    Commented Jul 11, 2017 at 12:24
  • As for "Save" example - faulted state is when for example checksum of the saved file differs from the expected, IMO.
    – pkuderov
    Commented Jul 11, 2017 at 12:26
  • @GlobalCharm yeah, those kinds of small and vague distinctions confused me. Naming is the first class problem all the time, you know. As someone said, there are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors ;)
    – pkuderov
    Commented Jul 11, 2017 at 12:33
  • 1
    @pkuderov In my view, messages from programs should follow established patterns that people are familiar with. For example, the log4j package in for Java has TRACE, DEBUG, INFO, WARNING, ERROR and FATAL. From what I have seen over the years, the person reading the error message eventually speaks to a developer or operator in search of a solution, and sometimes in an Agitated State of Mind. The less you have to take on in the way of explanation, the happier you (and everyone else) will be.
    – user205876
    Commented Jul 11, 2017 at 18:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.