Why don't we use "to generate" or "to get"?

E.g.: "External component has thrown an exception", "JavaScript had just thrown an error straight away", "Instances of Error objects are thrown when runtime errors occur".

  • An interesting question, but it seems you'd really have to ask the programming-language designers. (some programming languages use "raise", so "throw" is not a universal term.)
    – Hellion
    Apr 12, 2016 at 20:25
  • 4
    Most likely the term "throw" was originally chosen primarily because there is the mating term "catch", and the mechanisms involved need both aspects. "Send" and "receive" might have been used, but they already had a different, more general meaning in computing. Plus, "throw" in the sense of "throw a shoe" (from a horse) or "throw a rod" (in an automobile engine) already carried an implication of error or difficulty.
    – Hot Licks
    May 12, 2016 at 22:07
  • 1
    See also a similar question on Computer Science for a history of science perspective. Jun 6, 2018 at 0:06
  • Note that hardware traps are ancient. They caught exceptions. Later exploits threw error objects at them.
    – Phil Sweet
    Jul 14, 2023 at 17:41

5 Answers 5


see: https://en.wikipedia.org/wiki/Exception_handling at History

"... Software exception handling developed in Lisp in the 1960s and 1970s. This originated in LISP 1.5 (1962), where exceptions were caught by the ERRSET keyword, which returned NIL in case of an error, instead of terminating the program or entering the debugger.[10] Error raising was introduced in MacLisp in the late 1960s via the ERR keyword.[10] This was rapidly used not only for error raising, but for non-local control flow, and thus was augmented by two new keywords, CATCH and THROW (MacLisp June 1972), reserving ERRSET and ERR for error handling. ..."

  • 1
    As a programming language historian with an interest in Lisp, I can confirm this is exactly correct. An interesting side effect of this- is that originally throw and catch were meant as non exceptional escapes, rather than something that had gone wrong (as in Java today). For example, throw/catch would have been used specifically to early exit through a deep stack, notifying that some predicate was definitely false, WITHOUT being an error- if one intended an error condition, one would use the error system via ERRSET and ERR
    – mseddon
    Mar 4, 2020 at 20:51
  • 2
    For scholars- there appears to be a close connection between throw/catch in original Lisp, and Landin's J operator. But importantly, this upward escape was in no way needed to trigger a debugger, it was merely assumed to be a control flow construct like break or continue today.
    – mseddon
    Mar 4, 2020 at 20:55

The concept of exceptions originated in the programming language Lisp. Originally, a part of a program might cause an error to occur. You could specify a way for the program to continue executing on an error — in modern terminology, a way to handle the error. Then a mechanism was added to signal an error, i.e. to artificially cause an error condition, which allowed programmers to make use of the error handling mechanism for things that were not errors. This history is described in “A Pattern of Language Evolution” by Richard P. Gabriel and Guy L. Steele Jr..

The terms throw and catch appeared in 1972 in MACLISP. One of the first published work including those terms was the 1974 MACLISP Reference Manual by David A. Moon (§5.3 p.43). The mechanism is described as non-local exit. This means “jumping” from one point of the program to another, which generalizes what happens when an error occurs. The word exception was not used yet in the software community at the time. You didn't “throw an error” or “throw an exception” back then, you threw a value from one part of the program (the throw instruction) to another (the catch instruction), together with a tag indicating where to throw it to. Exceptions later evolved as a data structure combining the tag and the value.

  • Oh! I have made a comment to the same effect on a separate answer. Although- Lisp 1.5 used this mechanism only for errors, MacLisp extended it to throw/catch to support well-behaved dynamic exits. The remarkable idiosyncrasy with modern programming terminology (where throw must represent an exceptional condition) remains however, and that is definitely of note.
    – mseddon
    Mar 4, 2020 at 21:02

An attestation of "threw an error" on page 663 of The Electrical World and Engineer. New York, 1900.

And here's one of "throws an error": on page 323 of Productive Dairying. Philadelphia, 1917.

And here's one of "throws errors": on unknown page (thanks, Google) of Techniques of Plant Maintenance and Engineering. Madison Wisconsin, 1950.

  • These are interesting examples, since they're different in meaning to the usage in programming. All of them seem weird to me; I'd think they were English mistakes if I saw them in a modern piece of writing. I wonder whether they're etymologically related to the usage in programming.
    – Mark Amery
    Apr 21, 2019 at 18:18
  • @MarkAmery The first and last example seem normal enough to me – throw there is analogous to ‘throw a spanner in the works’. The second example seems quite odd to me as well. I’m not sure exactly what throw is actually supposed to mean in that example. Apr 21, 2019 at 18:59

This is a term specific to programming. Exceptions are 'thrown' which are 'caught' most often by an execution component. This shows the relationship between the exception, which is the initial event in the interaction, and the execution, which is a response event.

Quote from the Wikipedia article on Exception Handling:

"Software exception handling and the support provided by software tools differs somewhat from what is understood under exception in hardware, but similar concepts are involved. In programming language mechanisms for exception handling, the term exception is typically used in a specific sense to denote a data structure storing information about an exceptional condition. One mechanism to transfer control, or raise an exception, is known as a throw. The exception is said to be thrown. Execution is transferred to a "catch"."


It may not reflect the original etymology of the word, but one factor that makes the word apt for exception handling is that our model for how exceptions work ties into our existing notion of the call stack. In programming languages with functions or procedures, each nested function call causes the "call stack" to grow downwards, to a greater stack "depth". Less-nested calls are said to be "higher" on the call stack.

When an exception gets caught in a catch block (or except block, or rescue block, or whatever it's named in a particular language), that block is generally higher on the call stack than the point at which the exception occurred. Thus the two synonymous verbs we use to describe that event - either "raising" or "throwing" the exception - both make sense within the call stack metaphor. We can either imagine the exception rising through the call stack until it reaches the catch block that handles it, or we can imagine the deeper function "throwing" the exception up, like a ball, to the catch clause in a higher stack frame. Either way, the common point in the metaphor underlying both verbs is that exceptions travel upwards.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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