The Tartan language, designed during the process that eventually led to Ada, has a disable statement defined as follows:

A disable declaration in an inner block suppresses detection of the exceptions it names. A handler clause associates recovery code with a statement that may generate an exception (see section 4.7).
The disable declaration permits exceptions to be individually suppressed within a given scope. Should an exception occur when its detection is suppressed, the consequences are not defined. An exception must not be signalled or redeclared in a scope in which it is suppressed. Note that suppression of an exception is not an assertion that the condition that gives rise to the exception will not occur.

(Tartan reference manual, §6.4, emphasis mine)

It seems the disable statement has no other purpose than to trigger undefined behavior... what is the point of such a statement?

  • $\begingroup$ Perhaps it's meant as a "quick fix" of sorts—if some part of the code errors out in production, wrap it in a disable and debug it later. It allows the rest of the code to run regardless of error detection. $\endgroup$
    – Someone
    Nov 3 at 12:10
  • $\begingroup$ @Someone The spec states that if an exception occurs the consequences are undefined, so the code may not run if the error occurs (presuming I'm reading this correctly). Which is a little strange for a debugging feature... $\endgroup$
    – Ginger
    Nov 3 at 12:58
  • $\begingroup$ Then again, this makes sense—it's sloppily suppressing the error, which matches the sort of "quick fix" a lazy developer like me would use. $\endgroup$
    – Someone
    Nov 3 at 14:16
  • 4
    $\begingroup$ Presumably even though the behavior is undefined according to the spec, you would know how your specific implementation of the language handles it, and it would be something that's useful rather than C/C++-style language-lawyer nonsense. $\endgroup$ Nov 3 at 15:17
  • 1
    $\begingroup$ My best guess would be that it's an assertion that the exception won't be thrown, i.e. an unchecked reachability hint in order to allow optimisations. But the quoted text says explicitly that it's not supposed to be that. Perhaps then the spec is written that way to allow implementors to specify the behaviour in their own ways, and then the programmer can rely on the implementor's spec for it rather than the language spec. $\endgroup$
    – kaya3
    Nov 3 at 17:57

3 Answers 3


The purpose of this feature in Tartan is to satisfy the Ironman requirement 10G:

10G. Suppressing Exceptions. It shall be possible to suppress individually the detection of exceptions for software error situations. Should such a situation occur when its detection is suppressed, the consequences will be unpredictable

The "Strawman", "Woodenman", "Tinman" and "Ironman" versions of the Department of Defense Requirements for High Order Computer Programming Languages were released in sequence as part of that Ada development process. As the abstract of the Tartan paper notes, minimally satisfying all of the Ironman requirements was the primary goal of that language design.

In fact, the specification statement is exactly in the terms of the subsequent Steelman requirements, which had recently become available:

10G. Suppressing Exceptions. It shall be possible during translation to suppress individually the execution time detection of exceptions within a given scope. The language shall not guarantee the integrity of the values produced when a suppressed exception occurs. [Note that suppression of an exception is not an assertion that the corresponding error will not occur.]

The reason those requirements specified that detection of exceptional conditions should be able to be locally disabled was that the run-time costs of validating them could be significant on typical period hardware, such as requiring range checks on every access to a variable. This is explicit in requirement 10B:

10B. Error Situations. The errors detectable during execution shall include exceeding the specified range of an array subscript, exceeding the specified range of a variable, exceeding the implemented range of a variable, [...elided...]. [Note that some are very expensive to detect unless aided by special hardware, and consequently their detection will often be suppressed (see 10G).]

Thus a program could opt to avoid incurring these checks for a portion of the code where the performance cost of detecting them was unacceptable, either because that error was known not to occur or because the implementation's behaviour was acceptable in the cases where it did. This also made it into the final Ada definition in the form of the Suppress pragma, for the same reasons.

  • Department of Defense Requirements for High Order Computer Programming Languages, "Ironman". 14 January 1977. ADA100403. (alternative archive.org version)
  • Department of Defense Requirements for High Order Computer Programming Languages, "Steelman". 1 June 1978. ADA059444. (alternative wikisource text copy)
  • $\begingroup$ The link to the Ironman document link is borked for me -- it starts to show the PDF viewer but then I get an error loading page. $\endgroup$
    – Bbrk24
    Nov 4 at 1:15
  • $\begingroup$ It’s a working link to a regular PDF as far as I can tell, but the document is called “Department of Defense Requirements for High Order Computer Programming Languages”, 14 January 1977, and you can find it elsewhere too. $\endgroup$
    – Michael Homer
    Nov 4 at 1:24
  • $\begingroup$ When I look it up, I see "This document is not available in digital form. If you are supporting DoD or U.S. Government research please Sign In using a CAC, PIV or ECA or register with DTIC. Once registered, sign in, search for your document, and click on “Request Scanned Document”. If you are ineligible to register, you can request this document through FOIA." Are you logged in or on a VPN, perchance? $\endgroup$
    – Bbrk24
    Nov 4 at 1:35
  • 2
    $\begingroup$ Surprisingly, my house does not have privileged access to United States military information. This URL is in search engines (which is where I found the right version) so I don't think it's meant to be hidden at all. There is an archive.org version here that appears to be the same scan. $\endgroup$
    – Michael Homer
    Nov 4 at 1:52
  • $\begingroup$ Loads fine for me. Could be a region-dependent issue. $\endgroup$ Nov 4 at 14:01

In Tartan, and some other languages at that time, error reporting mechanisms are also used for trivial things like reaching EOF and integer overflow. This isn't very clear in the reference manual, but could be seen in the examples in section 4.7:

read(file,x) { on EOF -> goto Exit }
x := x+1 { on Overflow -> x := 0 }

The following is my speculation. If they happen unexpectedly, and no check is done, the code could be faulty. But if it never happens, doing the check would have some performance cost. So it might be helpful to give the user the control to turn it on and off.

It is a small detail that modern languages seem to not care about. Programmers seem never need it, unless they want the code to be extra safe, in which case they never turn it off. And most importantly, it doesn't seem easy to make user-defined exceptions take advantage like this, so it could only be a special case if supported.

  • 1
    $\begingroup$ Another possible issue, though this is just speculation not really worthy of an answer, is that in some cases the construct may be analogous to "battle shorts" in fuse blocks in some military vehicles. Normally, most vehicles, military or civilian, protect their circuits with fuses that will blow in case of overload, but some kinds of military equipment allow all such protections to be bypassed. The basic idea is that if a short circuit occurs in some sections of wiring during combat, bad things would be almost certain to happen if a fuse blows, and the consequences of bypassing the fuse... $\endgroup$
    – supercat
    Nov 6 at 4:51
  • $\begingroup$ ...would be slightly more likely to be survivable for the crew than having the fuse interrupt current. In many cases, having a system fail safely 100% of the time a condition arises may be better than having it succeed 90% the time the condition arises and fail dangerously the other 10%, but in some circumstances, it would be better for a system to have a 99% chance of failing in the worst possible way and a 1% chance of success, than to have a 100% chance of it failing in the least harmful way. Consider the New Horizons probe. Failsafes were disabled as it approached Pluto... $\endgroup$
    – supercat
    Nov 6 at 4:57
  • $\begingroup$ ...since a failsafe mechanism which resulted in the craft's operation being impaired for 20 minutes during the Pluto fly-by, but then allowed resumption fo communication after that, would if triggered be almost as bad as a failure which resulted in permanent loss of communication. For vehicles near Earth, avoiding crashing into things must be of maximum priority, but for something like the New Horizons probe, physics would make it impossible for even the most malicious software upload to cause the craft to hit something on Earth. $\endgroup$
    – supercat
    Nov 6 at 5:01

Although "performance reasons", as described in other answers, seems like an adequate explanation for why it would make sense to turn off error checks, I think it's also important to recognize that our modern understanding of "undefined behavior" has evolved a lot over time. My guess is that, at the time this was written (1978), it would have been understood to mean "whatever the implementation happens to do is fine, and whatever values happen to come out are fine". That is, I think it would have been closer to what we now would called "unspecified" or "implementation defined" behavior, rather than today's "nasal demons" definition of undefined behavior.

Even if the latter was technically a possible reading back then, probably nobody would read it that way, because it would have been fairly academic before the advent of today's hyper-aggressive optimizing compilers.

  • $\begingroup$ I'm not sure that "undefined behaviour" didn't also mean "nasal demons" in 1978. I think the reason for having undefined behaviour is the same. $\endgroup$
    – pxeger
    Nov 4 at 21:29
  • 1
    $\begingroup$ The actual phrase "nasal demons" was not coined until 1992. I think our modern definition of "undefined" comes from the C standard, which was first officially published in 1989, but I don't know if the current definition of undefined behavior was first found in that document, or some earlier or later one. $\endgroup$ Nov 4 at 21:37
  • $\begingroup$ Actually, even the first unofficial specification of the C language wasn't published until 1978. So if "undefined means no rules" comes originally from C, it can't predate that. It's possible C imported it from another language, but I'm not sure that languages having official standards/specification documents had even really caught on much yet, at that time? $\endgroup$ Nov 4 at 21:40
  • 2
    $\begingroup$ @michaelhomer Integrity of values, which seems to me a critical distinction. Under the C definition of undefined behavior, any instance of undefined behavior anywhere in an entire program automatically renders the entire program undefined. No part of it has any meaning or is guaranteed to do anything specific. My interpretation of "integrity of values" is that the result of the undefined computation may be wrong. This does not, to me, seem to imply that the entire program could format your hard drive, or send your nudes to CNN, in compliance with the standard. $\endgroup$ Nov 4 at 21:48
  • 1
    $\begingroup$ @GlennWillen: I find particularly interesting the bracketed note: "Note that suppression of an exception is not an assertion that the corresponding error will not occur." That expressly forbids some kinds of "optimizations" favored by [passive-]aggressive compiler writers. $\endgroup$
    – supercat
    Nov 5 at 20:02

You must log in to answer this question.

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