Что значит программная ошибка

A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and correcting bugs is termed «debugging» and often uses formal techniques or tools to pinpoint bugs. Since the 1950s, some computer systems have been designed to deter, detect or auto-correct various computer bugs during operations.

Bugs in software can arise from mistakes and errors made in interpreting and extracting users’ requirements, planning a program’s design, writing its source code, and from interaction with humans, hardware and programs, such as operating systems or libraries. A program with many, or serious, bugs is often described as buggy. Bugs can trigger errors that may have ripple effects. The effects of bugs may be subtle, such as unintended text formatting, through to more obvious effects such as causing a program to crash, freezing the computer, or causing damage to hardware. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls in order to obtain unauthorized privileges.^[1]

Some software bugs have been linked to disasters. Bugs in code that controlled the Therac-25 radiation therapy machine were directly responsible for patient deaths in the 1980s. In 1996, the European Space Agency’s US$1 billion prototype Ariane 5 rocket was destroyed less than a minute after launch due to a bug in the on-board guidance computer program.^[2] In 1994, an RAF Chinook helicopter crashed, killing 29; this was initially blamed on pilot error, but was later thought to have been caused by a software bug in the engine-control computer.^[3] Buggy software caused the early 21st century British Post Office scandal, the most widespread miscarriage of justice in British legal history.^[4]

In 2002, a study commissioned by the US Department of Commerce’s National Institute of Standards and Technology concluded that «software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product».^[5]

History[edit]

The Middle English word bugge is the basis for the terms «bugbear» and «bugaboo» as terms used for a monster.^[6]

The term «bug» to describe defects has been a part of engineering jargon since the 1870s^[7] and predates electronics and computers; it may have originally been used in hardware engineering to describe mechanical malfunctions. For instance, Thomas Edison wrote in a letter to an associate in 1878:^[8]

… difficulties arise—this thing gives out and [it is] then that «Bugs»—as such little faults and difficulties are called—show themselves^[9]

Baffle Ball, the first mechanical pinball game, was advertised as being «free of bugs» in 1931.^[10] Problems with military gear during World War II were referred to as bugs (or glitches).^[11] In a book published in 1942, Louise Dickinson Rich, speaking of a powered ice cutting machine, said, «Ice sawing was suspended until the creator could be brought in to take the bugs out of his darling.»^[12]

Isaac Asimov used the term «bug» to relate to issues with a robot in his short story «Catch That Rabbit», published in 1944.

The term «bug» was used in an account by computer pioneer Grace Hopper, who publicized the cause of a malfunction in an early electromechanical computer.^[13] A typical version of the story is:

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug.^[14]

Hopper was not present when the bug was found, but it became one of her favorite stories.^[15] The date in the log book was September 9, 1947.^[16][17][18] The operators who found it, including William «Bill» Burke, later of the Naval Weapons Laboratory, Dahlgren, Virginia,^[19] were familiar with the engineering term and amusedly kept the insect with the notation «First actual case of bug being found.» This log book, complete with attached moth, is part of the collection of the Smithsonian National Museum of American History.^[17]

The related term «debug» also appears to predate its usage in computing: the Oxford English Dictionary‘s etymology of the word contains an attestation from 1945, in the context of aircraft engines.^[20]

The concept that software might contain errors dates back to Ada Lovelace’s 1843 notes on the analytical engine, in which she speaks of the possibility of program «cards» for Charles Babbage’s analytical engine being erroneous:

… an analysing process must equally have been performed in order to furnish the Analytical Engine with the necessary operative data; and that herein may also lie a possible source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders.

«Bugs in the System» report[edit]

The Open Technology Institute, run by the group, New America,^[21] released a report «Bugs in the System» in August 2016 stating that U.S. policymakers should make reforms to help researchers identify and address software bugs. The report «highlights the need for reform in the field of software vulnerability discovery and disclosure.»^[22] One of the report’s authors said that Congress has not done enough to address cyber software vulnerability, even though Congress has passed a number of bills to combat the larger issue of cyber security.^[22]

Government researchers, companies, and cyber security experts are the people who typically discover software flaws. The report calls for reforming computer crime and copyright laws.^[22]

The Computer Fraud and Abuse Act, the Digital Millennium Copyright Act and the Electronic Communications Privacy Act criminalize and create civil penalties for actions that security researchers routinely engage in while conducting legitimate security research, the report said.^[22]

Terminology[edit]

While the use of the term «bug» to describe software errors is common, many have suggested that it should be abandoned. One argument is that the word «bug» is divorced from a sense that a human being caused the problem, and instead implies that the defect arose on its own, leading to a push to abandon the term «bug» in favor of terms such as «defect», with limited success.^[23] Since the 1970s Gary Kildall somewhat humorously suggested to use the term «blunder».^[24][25]

In software engineering, mistake metamorphism (from Greek meta = «change», morph = «form») refers to the evolution of a defect in the final stage of software deployment. Transformation of a «mistake» committed by an analyst in the early stages of the software development lifecycle, which leads to a «defect» in the final stage of the cycle has been called ‘mistake metamorphism’.^[26]

Different stages of a «mistake» in the entire cycle may be described as «mistakes», «anomalies», «faults», «failures», «errors», «exceptions», «crashes», «glitches», «bugs», «defects», «incidents», or «side effects».^[26]

Prevention[edit]

The software industry has put much effort into reducing bug counts.^[27][28] These include:

Typographical errors[edit]

Bugs usually appear when the programmer makes a logic error. Various innovations in programming style and defensive programming are designed to make these bugs less likely, or easier to spot. Some typos, especially of symbols or logical/mathematical operators, allow the program to operate incorrectly, while others such as a missing symbol or misspelled name may prevent the program from operating. Compiled languages can reveal some typos when the source code is compiled.

Development methodologies[edit]

Several schemes assist managing programmer activity so that fewer bugs are produced. Software engineering (which addresses software design issues as well) applies many techniques to prevent defects. For example, formal program specifications state the exact behavior of programs so that design bugs may be eliminated. Unfortunately, formal specifications are impractical for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy.

Unit testing involves writing a test for every function (unit) that a program is to perform.

In test-driven development unit tests are written before the code and the code is not considered complete until all tests complete successfully.

Agile software development involves frequent software releases with relatively small changes. Defects are revealed by user feedback.

Open source development allows anyone to examine source code. A school of thought popularized by Eric S. Raymond as Linus’s law says that popular open-source software has more chance of having few or no bugs than other software, because «given enough eyeballs, all bugs are shallow».^[29] This assertion has been disputed, however: computer security specialist Elias Levy wrote that «it is easy to hide vulnerabilities in complex, little understood and undocumented source code,» because, «even if people are reviewing the code, that doesn’t mean they’re qualified to do so.»^[30] An example of an open-source software bug was the 2008 OpenSSL vulnerability in Debian.

Programming language support[edit]

Programming languages include features to help prevent bugs, such as static type systems, restricted namespaces and modular programming. For example, when a programmer writes (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", although this may be syntactically correct, the code fails a type check. Compiled languages catch this without having to run the program. Interpreted languages catch such errors at runtime. Some languages deliberately exclude features that easily lead to bugs, at the expense of slower performance: the general principle being that, it is almost always better to write simpler, slower code than inscrutable code that runs slightly faster, especially considering that maintenance cost is substantial. For example, the Java programming language does not support pointer arithmetic; implementations of some languages such as Pascal and scripting languages often have runtime bounds checking of arrays, at least in a debugging build.

Code analysis[edit]

Tools for code analysis help developers by inspecting the program text beyond the compiler’s capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see halting problem), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes often when writing software.

Instrumentation[edit]

Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in the code explicitly (perhaps as simple as a statement saying PRINT "I AM HERE"), or provided as tools. It is often a surprise to find where most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten.

Testing[edit]

Software testers are people whose primary task is to find bugs, or write code to support testing. On some projects, more resources may be spent on testing than in developing the program.

Measurements during testing can provide an estimate of the number of likely bugs remaining; this becomes more reliable the longer a product is tested and developed.^{[citation needed]}

Debugging[edit]

Finding and fixing bugs, or debugging, is a major part of computer programming. Maurice Wilkes, an early computing pioneer, described his realization in the late 1940s that much of the rest of his life would be spent finding mistakes in his own programs.^[31]

Usually, the most difficult part of debugging is finding the bug. Once it is found, correcting it is usually relatively easy. Programs known as debuggers help programmers locate bugs by executing code line by line, watching variable values, and other features to observe program behavior. Without a debugger, code may be added so that messages or values may be written to a console or to a window or log file to trace program execution or show values.

However, even with the aid of a debugger, locating bugs is something of an art. It is not uncommon for a bug in one section of a program to cause failures in a completely different section,^{[citation needed]} thus making it especially difficult to track (for example, an error in a graphics rendering routine causing a file I/O routine to fail), in an apparently unrelated part of the system.

Sometimes, a bug is not an isolated flaw, but represents an error of thinking or planning on the part of the programmer. Such logic errors require a section of the program to be overhauled or rewritten. As a part of code review, stepping through the code and imagining or transcribing the execution process may often find errors without ever reproducing the bug as such.

More typically, the first step in locating a bug is to reproduce it reliably. Once the bug is reproducible, the programmer may use a debugger or other tool while reproducing the error to find the point at which the program went astray.

Some bugs are revealed by inputs that may be difficult for the programmer to re-create. One cause of the Therac-25 radiation machine deaths was a bug (specifically, a race condition) that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to duplicate it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running the program with a debugger; these are called heisenbugs (humorously named after the Heisenberg uncertainty principle).

Since the 1990s, particularly following the Ariane 5 Flight 501 disaster, interest in automated aids to debugging rose, such as static code analysis by abstract interpretation.^[32]

Some classes of bugs have nothing to do with the code. Faulty documentation or hardware may lead to problems in system use, even though the code matches the documentation. In some cases, changes to the code eliminate the problem even though the code then no longer matches the documentation. Embedded systems frequently work around hardware bugs, since to make a new version of a ROM is much cheaper than remanufacturing the hardware, especially if they are commodity items.

Benchmark of bugs[edit]

To facilitate reproducible research on testing and debugging, researchers use curated benchmarks of bugs:

• the Siemens benchmark
• ManyBugs^[33] is a benchmark of 185 C bugs in nine open-source programs.
• Defects4J^[34] is a benchmark of 341 Java bugs from 5 open-source projects. It contains the corresponding patches, which cover a variety of patch type.

Bug management[edit]

Bug management includes the process of documenting, categorizing, assigning, reproducing, correcting and releasing the corrected code. Proposed changes to software – bugs as well as enhancement requests and even entire releases – are commonly tracked and managed using bug tracking systems or issue tracking systems.^[35] The items added may be called defects, tickets, issues, or, following the agile development paradigm, stories and epics. Categories may be objective, subjective or a combination, such as version number, area of the software, severity and priority, as well as what type of issue it is, such as a feature request or a bug.

A bug triage reviews bugs and decides whether and when to fix them. The decision is based on the bug’s priority, and factors such as project schedules. The triage is not meant to investigate the cause of bugs, but rather the cost of fixing them. The triage happens regularly, and goes through bugs opened or reopened since the previous meeting. The attendees of the triage process typically are the project manager, development manager, test manager, build manager, and technical experts.^[36][37]

Severity[edit]

Severity is the intensity of the impact the bug has on system operation.^[38] This impact may be data loss, financial, loss of goodwill and wasted effort. Severity levels are not standardized. Impacts differ across industry. A crash in a video game has a totally different impact than a crash in a web browser, or real time monitoring system. For example, bug severity levels might be «crash or hang», «no workaround» (meaning there is no way the customer can accomplish a given task), «has workaround» (meaning the user can still accomplish the task), «visual defect» (for example, a missing image or displaced button or form element), or «documentation error». Some software publishers use more qualified severities such as «critical», «high», «low», «blocker» or «trivial».^[39] The severity of a bug may be a separate category to its priority for fixing, and the two may be quantified and managed separately.

Priority[edit]

Priority controls where a bug falls on the list of planned changes. The priority is decided by each software producer. Priorities may be numerical, such as 1 through 5, or named, such as «critical», «high», «low», or «deferred». These rating scales may be similar or even identical to severity ratings, but are evaluated as a combination of the bug’s severity with its estimated effort to fix; a bug with low severity but easy to fix may get a higher priority than a bug with moderate severity that requires excessive effort to fix. Priority ratings may be aligned with product releases, such as «critical» priority indicating all the bugs that must be fixed before the next software release.

A bug severe enough to delay or halt the release of the product is called a «show stopper»^[40] or «showstopper bug».^[41] It is named so because it «stops the show» – causes unacceptable product failure.^[41]

Software releases[edit]

It is common practice to release software with known, low-priority bugs. Bugs of sufficiently high priority may warrant a special release of part of the code containing only modules with those fixes. These are known as patches. Most releases include a mixture of behavior changes and multiple bug fixes. Releases that emphasize bug fixes are known as maintenance releases, to differentiate it from major releases that emphasize feature additions or changes.

Reasons that a software publisher opts not to patch or even fix a particular bug include:

• A deadline must be met and resources are insufficient to fix all bugs by the deadline.^[42]
• The bug is already fixed in an upcoming release, and it is not of high priority.
• The changes required to fix the bug are too costly or affect too many other components, requiring a major testing activity.
• It may be suspected, or known, that some users are relying on the existing buggy behavior; a proposed fix may introduce a breaking change.
• The problem is in an area that will be obsolete with an upcoming release; fixing it is unnecessary.
• «It’s not a bug, it’s a feature».^[43] A misunderstanding has arisen between expected and perceived behavior or undocumented feature.

Types[edit]

In software development projects, a mistake or error may be introduced at any stage. Bugs arise from oversight or misunderstanding by a software team during specification, design, coding, configuration, data entry or documentation. For example, a relatively simple program to alphabetize a list of words, the design might fail to consider what should happen when a word contains a hyphen. Or when converting an abstract design into code, the coder might inadvertently create an off-by-one error which can be a «<» where «<=» was intended, and fail to sort the last word in a list.

Another category of bug is called a race condition that may occur when programs have multiple components executing at the same time. If the components interact in a different order than the developer intended, they could interfere with each other and stop the program from completing its tasks. These bugs may be difficult to detect or anticipate, since they may not occur during every execution of a program.

Conceptual errors are a developer’s misunderstanding of what the software must do. The resulting software may perform according to the developer’s understanding, but not what is really needed. Other types:

Arithmetic[edit]

In operations on numerical values, problems can arise that result in unexpected output, slowing of a process, or crashing.^[44] These can be from a lack of awareness of the qualities of the data storage such as a loss of precision due to rounding, numerically unstable algorithms, arithmetic overflow and underflow, or from lack of awareness of how calculations are handled by different software coding languages such as division by zero which in some languages may throw an exception, and in others may return a special value such as NaN or infinity.

Control flow[edit]

Control flow bugs are those found in processes with valid logic, but that lead to unintended results, such as infinite loops and infinite recursion, incorrect comparisons for conditional statements such as using the incorrect comparison operator, and off-by-one errors (counting one too many or one too few iterations when looping).

Interfacing[edit]

• Incorrect API usage.
• Incorrect protocol implementation.
• Incorrect hardware handling.
• Incorrect assumptions of a particular platform.
• Incompatible systems. A new API or communications protocol may seem to work when two systems use different versions, but errors may occur when a function or feature implemented in one version is changed or missing in another. In production systems which must run continually, shutting down the entire system for a major update may not be possible, such as in the telecommunication industry^[45] or the internet.^[46][47][48] In this case, smaller segments of a large system are upgraded individually, to minimize disruption to a large network. However, some sections could be overlooked and not upgraded, and cause compatibility errors which may be difficult to find and repair.
• Incorrect code annotations.

Concurrency[edit]

• Deadlock, where task A cannot continue until task B finishes, but at the same time, task B cannot continue until task A finishes.
• Race condition, where the computer does not perform tasks in the order the programmer intended.
• Concurrency errors in critical sections, mutual exclusions and other features of concurrent processing. Time-of-check-to-time-of-use (TOCTOU) is a form of unprotected critical section.

Resourcing[edit]

• Null pointer dereference.
• Using an uninitialized variable.
• Using an otherwise valid instruction on the wrong data type (see packed decimal/binary-coded decimal).
• Access violations.
• Resource leaks, where a finite system resource (such as memory or file handles) become exhausted by repeated allocation without release.
• Buffer overflow, in which a program tries to store data past the end of allocated storage. This may or may not lead to an access violation or storage violation. These are frequently security bugs.
• Excessive recursion which—though logically valid—causes stack overflow.
• Use-after-free error, where a pointer is used after the system has freed the memory it references.
• Double free error.

Syntax[edit]

• Use of the wrong token, such as performing assignment instead of equality test. For example, in some languages x=5 will set the value of x to 5 while x==5 will check whether x is currently 5 or some other number. Interpreted languages allow such code to fail. Compiled languages can catch such errors before testing begins.

Teamwork[edit]

• Unpropagated updates; e.g. programmer changes «myAdd» but forgets to change «mySubtract», which uses the same algorithm. These errors are mitigated by the Don’t Repeat Yourself philosophy.
• Comments out of date or incorrect: many programmers assume the comments accurately describe the code.
• Differences between documentation and product.

Implications[edit]

The amount and type of damage a software bug may cause naturally affects decision-making, processes and policy regarding software quality. In applications such as human spaceflight, aviation, nuclear power, health care, public transport or automotive safety, since software flaws have the potential to cause human injury or even death, such software will have far more scrutiny and quality control than, for example, an online shopping website. In applications such as banking, where software flaws have the potential to cause serious financial damage to a bank or its customers, quality control is also more important than, say, a photo editing application.

Other than the damage caused by bugs, some of their cost is due to the effort invested in fixing them. In 1978, Lientz et al. showed that the median of projects invest 17 percent of the development effort in bug fixing.^[49] In research in 2020 on GitHub repositories showed the median is 20%.^[50]

Residual bugs in delivered product[edit]

In 1994, NASA’s Goddard Space Flight Center managed to reduce their average number of errors from 4.5 per 1000 lines of code (SLOC) down to 1 per 1000 SLOC.^[51]

Another study in 1990 reported that exceptionally good software development processes can achieve deployment failure rates as low as 0.1 per 1000 SLOC.^[52] This figure is iterated in literature such as Code Complete by Steve McConnell,^[53] and the NASA study on Flight Software Complexity.^[54] Some projects even attained zero defects: the firmware in the IBM Wheelwriter typewriter which consists of 63,000 SLOC, and the Space Shuttle software with 500,000 SLOC.^[52]

Well-known bugs[edit]

A number of software bugs have become well-known, usually due to their severity: examples include various space and military aircraft crashes. Possibly the most famous bug is the Year 2000 problem or Y2K bug, which caused many programs written long before the transition from 19xx to 20xx dates to malfunction, for example treating a date such as «25 Dec 04» as being in 1904, displaying «19100» instead of «2000», and so on. A huge effort at the end of the 20th century resolved the most severe problems, and there were no major consequences.

The 2012 stock trading disruption involved one such incompatibility between the old API and a new API.

In popular culture[edit]

• In both the 1968 novel 2001: A Space Odyssey and the corresponding 1968 film 2001: A Space Odyssey, a spaceship’s onboard computer, HAL 9000, attempts to kill all its crew members. In the follow-up 1982 novel, 2010: Odyssey Two, and the accompanying 1984 film, 2010, it is revealed that this action was caused by the computer having been programmed with two conflicting objectives: to fully disclose all its information, and to keep the true purpose of the flight secret from the crew; this conflict caused HAL to become paranoid and eventually homicidal.
• In the English version of the Nena 1983 song 99 Luftballons (99 Red Balloons) as a result of «bugs in the software», a release of a group of 99 red balloons are mistaken for an enemy nuclear missile launch, requiring an equivalent launch response, resulting in catastrophe.
• In the 1999 American comedy Office Space, three employees attempt (unsuccessfully) to exploit their company’s preoccupation with the Y2K computer bug using a computer virus that sends rounded-off fractions of a penny to their bank account—a long-known technique described as salami slicing.
• The 2004 novel The Bug, by Ellen Ullman, is about a programmer’s attempt to find an elusive bug in a database application.^[55]
• The 2008 Canadian film Control Alt Delete is about a computer programmer at the end of 1999 struggling to fix bugs at his company related to the year 2000 problem.

See also[edit]

• Anti-pattern
• Bug bounty program
• Glitch removal
• Hardware bug
• ISO/IEC 9126, which classifies a bug as either a defect or a nonconformity
• Orthogonal Defect Classification
• Racetrack problem
• RISKS Digest
• Software defect indicator
• Software regression
• Software rot
• Automatic bug fixing

References[edit]

External links[edit]

• «Common Weakness Enumeration» – an expert webpage focus on bugs, at NIST.gov
• BUG type of Jim Gray – another Bug type
• Picture of the «first computer bug» at the Wayback Machine (archived January 12, 2015)
• «The First Computer Bug!» – an email from 1981 about Adm. Hopper’s bug
• «Toward Understanding Compiler Bugs in GCC and LLVM». A 2016 study of bugs in compilers

A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and correcting bugs is termed «debugging» and often uses formal techniques or tools to pinpoint bugs. Since the 1950s, some computer systems have been designed to deter, detect or auto-correct various computer bugs during operations.

Bugs in software can arise from mistakes and errors made in interpreting and extracting users’ requirements, planning a program’s design, writing its source code, and from interaction with humans, hardware and programs, such as operating systems or libraries. A program with many, or serious, bugs is often described as buggy. Bugs can trigger errors that may have ripple effects. The effects of bugs may be subtle, such as unintended text formatting, through to more obvious effects such as causing a program to crash, freezing the computer, or causing damage to hardware. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls in order to obtain unauthorized privileges.^[1]

Some software bugs have been linked to disasters. Bugs in code that controlled the Therac-25 radiation therapy machine were directly responsible for patient deaths in the 1980s. In 1996, the European Space Agency’s US$1 billion prototype Ariane 5 rocket was destroyed less than a minute after launch due to a bug in the on-board guidance computer program.^[2] In 1994, an RAF Chinook helicopter crashed, killing 29; this was initially blamed on pilot error, but was later thought to have been caused by a software bug in the engine-control computer.^[3] Buggy software caused the early 21st century British Post Office scandal, the most widespread miscarriage of justice in British legal history.^[4]

In 2002, a study commissioned by the US Department of Commerce’s National Institute of Standards and Technology concluded that «software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product».^[5]

History[edit]

The Middle English word bugge is the basis for the terms «bugbear» and «bugaboo» as terms used for a monster.^[6]

The term «bug» to describe defects has been a part of engineering jargon since the 1870s^[7] and predates electronics and computers; it may have originally been used in hardware engineering to describe mechanical malfunctions. For instance, Thomas Edison wrote in a letter to an associate in 1878:^[8]

… difficulties arise—this thing gives out and [it is] then that «Bugs»—as such little faults and difficulties are called—show themselves^[9]

Baffle Ball, the first mechanical pinball game, was advertised as being «free of bugs» in 1931.^[10] Problems with military gear during World War II were referred to as bugs (or glitches).^[11] In a book published in 1942, Louise Dickinson Rich, speaking of a powered ice cutting machine, said, «Ice sawing was suspended until the creator could be brought in to take the bugs out of his darling.»^[12]

Isaac Asimov used the term «bug» to relate to issues with a robot in his short story «Catch That Rabbit», published in 1944.

The term «bug» was used in an account by computer pioneer Grace Hopper, who publicized the cause of a malfunction in an early electromechanical computer.^[13] A typical version of the story is:

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug.^[14]

Hopper was not present when the bug was found, but it became one of her favorite stories.^[15] The date in the log book was September 9, 1947.^[16][17][18] The operators who found it, including William «Bill» Burke, later of the Naval Weapons Laboratory, Dahlgren, Virginia,^[19] were familiar with the engineering term and amusedly kept the insect with the notation «First actual case of bug being found.» This log book, complete with attached moth, is part of the collection of the Smithsonian National Museum of American History.^[17]

The related term «debug» also appears to predate its usage in computing: the Oxford English Dictionary‘s etymology of the word contains an attestation from 1945, in the context of aircraft engines.^[20]

The concept that software might contain errors dates back to Ada Lovelace’s 1843 notes on the analytical engine, in which she speaks of the possibility of program «cards» for Charles Babbage’s analytical engine being erroneous:

… an analysing process must equally have been performed in order to furnish the Analytical Engine with the necessary operative data; and that herein may also lie a possible source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders.

«Bugs in the System» report[edit]

The Open Technology Institute, run by the group, New America,^[21] released a report «Bugs in the System» in August 2016 stating that U.S. policymakers should make reforms to help researchers identify and address software bugs. The report «highlights the need for reform in the field of software vulnerability discovery and disclosure.»^[22] One of the report’s authors said that Congress has not done enough to address cyber software vulnerability, even though Congress has passed a number of bills to combat the larger issue of cyber security.^[22]

Government researchers, companies, and cyber security experts are the people who typically discover software flaws. The report calls for reforming computer crime and copyright laws.^[22]

The Computer Fraud and Abuse Act, the Digital Millennium Copyright Act and the Electronic Communications Privacy Act criminalize and create civil penalties for actions that security researchers routinely engage in while conducting legitimate security research, the report said.^[22]

Terminology[edit]

While the use of the term «bug» to describe software errors is common, many have suggested that it should be abandoned. One argument is that the word «bug» is divorced from a sense that a human being caused the problem, and instead implies that the defect arose on its own, leading to a push to abandon the term «bug» in favor of terms such as «defect», with limited success.^[23] Since the 1970s Gary Kildall somewhat humorously suggested to use the term «blunder».^[24][25]

In software engineering, mistake metamorphism (from Greek meta = «change», morph = «form») refers to the evolution of a defect in the final stage of software deployment. Transformation of a «mistake» committed by an analyst in the early stages of the software development lifecycle, which leads to a «defect» in the final stage of the cycle has been called ‘mistake metamorphism’.^[26]

Different stages of a «mistake» in the entire cycle may be described as «mistakes», «anomalies», «faults», «failures», «errors», «exceptions», «crashes», «glitches», «bugs», «defects», «incidents», or «side effects».^[26]

Prevention[edit]

The software industry has put much effort into reducing bug counts.^[27][28] These include:

Typographical errors[edit]

Bugs usually appear when the programmer makes a logic error. Various innovations in programming style and defensive programming are designed to make these bugs less likely, or easier to spot. Some typos, especially of symbols or logical/mathematical operators, allow the program to operate incorrectly, while others such as a missing symbol or misspelled name may prevent the program from operating. Compiled languages can reveal some typos when the source code is compiled.

Development methodologies[edit]

Several schemes assist managing programmer activity so that fewer bugs are produced. Software engineering (which addresses software design issues as well) applies many techniques to prevent defects. For example, formal program specifications state the exact behavior of programs so that design bugs may be eliminated. Unfortunately, formal specifications are impractical for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy.

Unit testing involves writing a test for every function (unit) that a program is to perform.

In test-driven development unit tests are written before the code and the code is not considered complete until all tests complete successfully.

Agile software development involves frequent software releases with relatively small changes. Defects are revealed by user feedback.

Open source development allows anyone to examine source code. A school of thought popularized by Eric S. Raymond as Linus’s law says that popular open-source software has more chance of having few or no bugs than other software, because «given enough eyeballs, all bugs are shallow».^[29] This assertion has been disputed, however: computer security specialist Elias Levy wrote that «it is easy to hide vulnerabilities in complex, little understood and undocumented source code,» because, «even if people are reviewing the code, that doesn’t mean they’re qualified to do so.»^[30] An example of an open-source software bug was the 2008 OpenSSL vulnerability in Debian.

Programming language support[edit]

Programming languages include features to help prevent bugs, such as static type systems, restricted namespaces and modular programming. For example, when a programmer writes (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", although this may be syntactically correct, the code fails a type check. Compiled languages catch this without having to run the program. Interpreted languages catch such errors at runtime. Some languages deliberately exclude features that easily lead to bugs, at the expense of slower performance: the general principle being that, it is almost always better to write simpler, slower code than inscrutable code that runs slightly faster, especially considering that maintenance cost is substantial. For example, the Java programming language does not support pointer arithmetic; implementations of some languages such as Pascal and scripting languages often have runtime bounds checking of arrays, at least in a debugging build.

Code analysis[edit]

Tools for code analysis help developers by inspecting the program text beyond the compiler’s capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see halting problem), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes often when writing software.

Instrumentation[edit]

Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in the code explicitly (perhaps as simple as a statement saying PRINT "I AM HERE"), or provided as tools. It is often a surprise to find where most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten.

Testing[edit]

Software testers are people whose primary task is to find bugs, or write code to support testing. On some projects, more resources may be spent on testing than in developing the program.

Measurements during testing can provide an estimate of the number of likely bugs remaining; this becomes more reliable the longer a product is tested and developed.^{[citation needed]}

Debugging[edit]

Finding and fixing bugs, or debugging, is a major part of computer programming. Maurice Wilkes, an early computing pioneer, described his realization in the late 1940s that much of the rest of his life would be spent finding mistakes in his own programs.^[31]

Usually, the most difficult part of debugging is finding the bug. Once it is found, correcting it is usually relatively easy. Programs known as debuggers help programmers locate bugs by executing code line by line, watching variable values, and other features to observe program behavior. Without a debugger, code may be added so that messages or values may be written to a console or to a window or log file to trace program execution or show values.

However, even with the aid of a debugger, locating bugs is something of an art. It is not uncommon for a bug in one section of a program to cause failures in a completely different section,^{[citation needed]} thus making it especially difficult to track (for example, an error in a graphics rendering routine causing a file I/O routine to fail), in an apparently unrelated part of the system.

Sometimes, a bug is not an isolated flaw, but represents an error of thinking or planning on the part of the programmer. Such logic errors require a section of the program to be overhauled or rewritten. As a part of code review, stepping through the code and imagining or transcribing the execution process may often find errors without ever reproducing the bug as such.

More typically, the first step in locating a bug is to reproduce it reliably. Once the bug is reproducible, the programmer may use a debugger or other tool while reproducing the error to find the point at which the program went astray.

Some bugs are revealed by inputs that may be difficult for the programmer to re-create. One cause of the Therac-25 radiation machine deaths was a bug (specifically, a race condition) that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to duplicate it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running the program with a debugger; these are called heisenbugs (humorously named after the Heisenberg uncertainty principle).

Since the 1990s, particularly following the Ariane 5 Flight 501 disaster, interest in automated aids to debugging rose, such as static code analysis by abstract interpretation.^[32]

Some classes of bugs have nothing to do with the code. Faulty documentation or hardware may lead to problems in system use, even though the code matches the documentation. In some cases, changes to the code eliminate the problem even though the code then no longer matches the documentation. Embedded systems frequently work around hardware bugs, since to make a new version of a ROM is much cheaper than remanufacturing the hardware, especially if they are commodity items.

Benchmark of bugs[edit]

To facilitate reproducible research on testing and debugging, researchers use curated benchmarks of bugs:

• the Siemens benchmark
• ManyBugs^[33] is a benchmark of 185 C bugs in nine open-source programs.
• Defects4J^[34] is a benchmark of 341 Java bugs from 5 open-source projects. It contains the corresponding patches, which cover a variety of patch type.

Bug management[edit]

Bug management includes the process of documenting, categorizing, assigning, reproducing, correcting and releasing the corrected code. Proposed changes to software – bugs as well as enhancement requests and even entire releases – are commonly tracked and managed using bug tracking systems or issue tracking systems.^[35] The items added may be called defects, tickets, issues, or, following the agile development paradigm, stories and epics. Categories may be objective, subjective or a combination, such as version number, area of the software, severity and priority, as well as what type of issue it is, such as a feature request or a bug.

A bug triage reviews bugs and decides whether and when to fix them. The decision is based on the bug’s priority, and factors such as project schedules. The triage is not meant to investigate the cause of bugs, but rather the cost of fixing them. The triage happens regularly, and goes through bugs opened or reopened since the previous meeting. The attendees of the triage process typically are the project manager, development manager, test manager, build manager, and technical experts.^[36][37]

Severity[edit]

Severity is the intensity of the impact the bug has on system operation.^[38] This impact may be data loss, financial, loss of goodwill and wasted effort. Severity levels are not standardized. Impacts differ across industry. A crash in a video game has a totally different impact than a crash in a web browser, or real time monitoring system. For example, bug severity levels might be «crash or hang», «no workaround» (meaning there is no way the customer can accomplish a given task), «has workaround» (meaning the user can still accomplish the task), «visual defect» (for example, a missing image or displaced button or form element), or «documentation error». Some software publishers use more qualified severities such as «critical», «high», «low», «blocker» or «trivial».^[39] The severity of a bug may be a separate category to its priority for fixing, and the two may be quantified and managed separately.

Priority[edit]

Priority controls where a bug falls on the list of planned changes. The priority is decided by each software producer. Priorities may be numerical, such as 1 through 5, or named, such as «critical», «high», «low», or «deferred». These rating scales may be similar or even identical to severity ratings, but are evaluated as a combination of the bug’s severity with its estimated effort to fix; a bug with low severity but easy to fix may get a higher priority than a bug with moderate severity that requires excessive effort to fix. Priority ratings may be aligned with product releases, such as «critical» priority indicating all the bugs that must be fixed before the next software release.

A bug severe enough to delay or halt the release of the product is called a «show stopper»^[40] or «showstopper bug».^[41] It is named so because it «stops the show» – causes unacceptable product failure.^[41]

Software releases[edit]

It is common practice to release software with known, low-priority bugs. Bugs of sufficiently high priority may warrant a special release of part of the code containing only modules with those fixes. These are known as patches. Most releases include a mixture of behavior changes and multiple bug fixes. Releases that emphasize bug fixes are known as maintenance releases, to differentiate it from major releases that emphasize feature additions or changes.

Reasons that a software publisher opts not to patch or even fix a particular bug include:

• A deadline must be met and resources are insufficient to fix all bugs by the deadline.^[42]
• The bug is already fixed in an upcoming release, and it is not of high priority.
• The changes required to fix the bug are too costly or affect too many other components, requiring a major testing activity.
• It may be suspected, or known, that some users are relying on the existing buggy behavior; a proposed fix may introduce a breaking change.
• The problem is in an area that will be obsolete with an upcoming release; fixing it is unnecessary.
• «It’s not a bug, it’s a feature».^[43] A misunderstanding has arisen between expected and perceived behavior or undocumented feature.

Types[edit]

In software development projects, a mistake or error may be introduced at any stage. Bugs arise from oversight or misunderstanding by a software team during specification, design, coding, configuration, data entry or documentation. For example, a relatively simple program to alphabetize a list of words, the design might fail to consider what should happen when a word contains a hyphen. Or when converting an abstract design into code, the coder might inadvertently create an off-by-one error which can be a «<» where «<=» was intended, and fail to sort the last word in a list.

Another category of bug is called a race condition that may occur when programs have multiple components executing at the same time. If the components interact in a different order than the developer intended, they could interfere with each other and stop the program from completing its tasks. These bugs may be difficult to detect or anticipate, since they may not occur during every execution of a program.

Conceptual errors are a developer’s misunderstanding of what the software must do. The resulting software may perform according to the developer’s understanding, but not what is really needed. Other types:

Arithmetic[edit]

In operations on numerical values, problems can arise that result in unexpected output, slowing of a process, or crashing.^[44] These can be from a lack of awareness of the qualities of the data storage such as a loss of precision due to rounding, numerically unstable algorithms, arithmetic overflow and underflow, or from lack of awareness of how calculations are handled by different software coding languages such as division by zero which in some languages may throw an exception, and in others may return a special value such as NaN or infinity.

Control flow[edit]

Control flow bugs are those found in processes with valid logic, but that lead to unintended results, such as infinite loops and infinite recursion, incorrect comparisons for conditional statements such as using the incorrect comparison operator, and off-by-one errors (counting one too many or one too few iterations when looping).

Interfacing[edit]

• Incorrect API usage.
• Incorrect protocol implementation.
• Incorrect hardware handling.
• Incorrect assumptions of a particular platform.
• Incompatible systems. A new API or communications protocol may seem to work when two systems use different versions, but errors may occur when a function or feature implemented in one version is changed or missing in another. In production systems which must run continually, shutting down the entire system for a major update may not be possible, such as in the telecommunication industry^[45] or the internet.^[46][47][48] In this case, smaller segments of a large system are upgraded individually, to minimize disruption to a large network. However, some sections could be overlooked and not upgraded, and cause compatibility errors which may be difficult to find and repair.
• Incorrect code annotations.

Concurrency[edit]

• Deadlock, where task A cannot continue until task B finishes, but at the same time, task B cannot continue until task A finishes.
• Race condition, where the computer does not perform tasks in the order the programmer intended.
• Concurrency errors in critical sections, mutual exclusions and other features of concurrent processing. Time-of-check-to-time-of-use (TOCTOU) is a form of unprotected critical section.

Resourcing[edit]

• Null pointer dereference.
• Using an uninitialized variable.
• Using an otherwise valid instruction on the wrong data type (see packed decimal/binary-coded decimal).
• Access violations.
• Resource leaks, where a finite system resource (such as memory or file handles) become exhausted by repeated allocation without release.
• Buffer overflow, in which a program tries to store data past the end of allocated storage. This may or may not lead to an access violation or storage violation. These are frequently security bugs.
• Excessive recursion which—though logically valid—causes stack overflow.
• Use-after-free error, where a pointer is used after the system has freed the memory it references.
• Double free error.

Syntax[edit]

• Use of the wrong token, such as performing assignment instead of equality test. For example, in some languages x=5 will set the value of x to 5 while x==5 will check whether x is currently 5 or some other number. Interpreted languages allow such code to fail. Compiled languages can catch such errors before testing begins.

Teamwork[edit]

• Unpropagated updates; e.g. programmer changes «myAdd» but forgets to change «mySubtract», which uses the same algorithm. These errors are mitigated by the Don’t Repeat Yourself philosophy.
• Comments out of date or incorrect: many programmers assume the comments accurately describe the code.
• Differences between documentation and product.

Implications[edit]

The amount and type of damage a software bug may cause naturally affects decision-making, processes and policy regarding software quality. In applications such as human spaceflight, aviation, nuclear power, health care, public transport or automotive safety, since software flaws have the potential to cause human injury or even death, such software will have far more scrutiny and quality control than, for example, an online shopping website. In applications such as banking, where software flaws have the potential to cause serious financial damage to a bank or its customers, quality control is also more important than, say, a photo editing application.

Other than the damage caused by bugs, some of their cost is due to the effort invested in fixing them. In 1978, Lientz et al. showed that the median of projects invest 17 percent of the development effort in bug fixing.^[49] In research in 2020 on GitHub repositories showed the median is 20%.^[50]

Residual bugs in delivered product[edit]

In 1994, NASA’s Goddard Space Flight Center managed to reduce their average number of errors from 4.5 per 1000 lines of code (SLOC) down to 1 per 1000 SLOC.^[51]

Another study in 1990 reported that exceptionally good software development processes can achieve deployment failure rates as low as 0.1 per 1000 SLOC.^[52] This figure is iterated in literature such as Code Complete by Steve McConnell,^[53] and the NASA study on Flight Software Complexity.^[54] Some projects even attained zero defects: the firmware in the IBM Wheelwriter typewriter which consists of 63,000 SLOC, and the Space Shuttle software with 500,000 SLOC.^[52]

Well-known bugs[edit]

A number of software bugs have become well-known, usually due to their severity: examples include various space and military aircraft crashes. Possibly the most famous bug is the Year 2000 problem or Y2K bug, which caused many programs written long before the transition from 19xx to 20xx dates to malfunction, for example treating a date such as «25 Dec 04» as being in 1904, displaying «19100» instead of «2000», and so on. A huge effort at the end of the 20th century resolved the most severe problems, and there were no major consequences.

The 2012 stock trading disruption involved one such incompatibility between the old API and a new API.

In popular culture[edit]

• In both the 1968 novel 2001: A Space Odyssey and the corresponding 1968 film 2001: A Space Odyssey, a spaceship’s onboard computer, HAL 9000, attempts to kill all its crew members. In the follow-up 1982 novel, 2010: Odyssey Two, and the accompanying 1984 film, 2010, it is revealed that this action was caused by the computer having been programmed with two conflicting objectives: to fully disclose all its information, and to keep the true purpose of the flight secret from the crew; this conflict caused HAL to become paranoid and eventually homicidal.
• In the English version of the Nena 1983 song 99 Luftballons (99 Red Balloons) as a result of «bugs in the software», a release of a group of 99 red balloons are mistaken for an enemy nuclear missile launch, requiring an equivalent launch response, resulting in catastrophe.
• In the 1999 American comedy Office Space, three employees attempt (unsuccessfully) to exploit their company’s preoccupation with the Y2K computer bug using a computer virus that sends rounded-off fractions of a penny to their bank account—a long-known technique described as salami slicing.
• The 2004 novel The Bug, by Ellen Ullman, is about a programmer’s attempt to find an elusive bug in a database application.^[55]
• The 2008 Canadian film Control Alt Delete is about a computer programmer at the end of 1999 struggling to fix bugs at his company related to the year 2000 problem.

See also[edit]

• Anti-pattern
• Bug bounty program
• Glitch removal
• Hardware bug
• ISO/IEC 9126, which classifies a bug as either a defect or a nonconformity
• Orthogonal Defect Classification
• Racetrack problem
• RISKS Digest
• Software defect indicator
• Software regression
• Software rot
• Automatic bug fixing

References[edit]

External links[edit]

• «Common Weakness Enumeration» – an expert webpage focus on bugs, at NIST.gov
• BUG type of Jim Gray – another Bug type
• Picture of the «first computer bug» at the Wayback Machine (archived January 12, 2015)
• «The First Computer Bug!» – an email from 1981 about Adm. Hopper’s bug
• «Toward Understanding Compiler Bugs in GCC and LLVM». A 2016 study of bugs in compilers

 vlada_maestro / shutterstock

Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.

В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.

Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:

//В конце команды забыли поставить точку с запятой (;)
int a = 5

Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.

Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:

int main()
{
   //Мы создаём две переменные, которые просто занимают память и никак не используются
   int a, b;
}

Мы можем попросить компилятор показать нам все предупреждения с помощью флага -Wall:

Предупреждения не являются чем-то критичным, но могут иметь негативные последствия. Например, ваша программа будет использовать больше памяти, чем должна. Так как C++ нужен в том числе и для разработки высоконагруженных систем, этого допускать нельзя.

После восклицательного знака в треугольнике — количество предупреждений

Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:

//Создаём константный массив символов 
const char * s = "Hello World";
//Если мы попытаемся перезаписать значение константы, компилятор выдаст ошибку
//Но с помощью указателей мы можем обойти её, поэтому программа успешно скомпилируется
//Однако во время работы она будет выдавать ошибку сегментации
* (char *) s = 'H';

Вот результат работы такого кода:

Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:

Но они могут привести и к более серьёзным последствиям. Если неправильно спроектировать работу многопоточного приложения, то потоки будут постоянно опережать друг друга. Например, сообщение об ошибке из одного потока может опоздать на миллисекунду, из-за чего второй поток подумает, что никакой ошибки не было, и продолжит работу.

Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.

Также во время работы программы могут возникать ситуации, которые мешают корректной работе программы. Например, если вы просите пользователя ввести число, а он вводит строку.

Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.

Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.

Одно из самых известных исключений — переполнение стека (англ. stack overflow). В честь него даже назвали сайт, на котором программисты ищут помощь в решении своих проблем.

int main()
{
   //Бесконечная рекурсия - одна из причин переполнения стека вызовов
   main();
}

Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:

Вот аналогичный код на языке C#:

class Program
{
   static void Main(string[] args)
   {
       Main(args);
   }
}

Однако сообщение в этот раз более конкретное:

В обоих случаях программа завершается, потому что не может дальше корректно работать.

Похожая ситуация — переполнение буфера (англ. buffer overflow). Она происходит, когда записываемое значение больше выделенной области в памяти.

//Пробуем записать в переменную типа int значение, которое превышает лимит
//Константа INT_MAX находится в библиотеке climits
int a = INT_MAX + 1;

Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):

Тем не менее программа скомпилировалась. Если же такая ситуация возникнет во время вычислений, то мы можем не получить предупреждения.

Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.

К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.

Один из таких инструментов — отладчик. Он помогает контролировать ход работы программы, чтобы отслеживать разные показатели.

Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.

Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:

Входные данные	Ожидаемый результат
5, 10	15
99, 99	198
8, -9	-1
-1, -1	-2
fff, 8	IllegalArgumentException

Если какой-то из этих тестов не пройден, вы узнаете об этом и сможете всё исправить. Это намного быстрее, чем проверять всё вручную.

Ошибок существует слишком много. При этом самые опасные тяжелее обнаружить, что только усугубляет ситуацию.

Школа дронов для всех
Учим программировать беспилотники и управлять ими.
Узнать больше

Ошибки в программировании – дело обычное, хоть и неприятное. В данной статье будет рассказано о том, какими бывают ошибки (баги), а также что собой представляют исключения.

Определение

Ошибка в программировании (или так называемый баг) – это ситуация у разработчиков, при которой определенный код вследствие обработки выдает неверный результат. Причин данному явлению множество: неисправность компилятора, сбои интерфейса, неточности и нарушения в программном коде.

Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:

1. Появляется сообщение об ошибке, но приложение продолжает функционировать.
2. ПО вылетает или зависает. Никаких предупреждений или предпосылок этому не было. Процедура осуществляется неожиданно для пользователя. Возможен вариант, при котором контент перезапускается самостоятельно и непредсказуемо.
3. Одно из событий, описанных ранее, сопровождается отправкой отчетов разработчикам.

Ошибки в программах могут привести соответствующее приложение в негодность, а также к непредсказуемым алгоритмам функционирования. Желательно обнаруживать баги на этапе ранней разработки или тестирования. Лишь в этом случае программист сможет оперативно и относительно недорого внести необходимые изменения в код для отладки ПО.

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

1. 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
2. Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.

Как классифицируют

Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:

1. Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
2. Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
3. Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.

Последний вариант требует особого внимания со стороны программистов. Их стараются обнаружить и устранить в первую очередь. Критические ошибки могут отложить релиз исходной программы на неопределенный срок.

Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.

Иногда может получиться так, что ошибка возникает только на устройстве конкретного пользователя. В данном случае устранение неполадки требует индивидуального подхода. Иногда – полной замены компьютера. Связано это с тем, что никто не будет редактировать исходный код, когда он «глючит» только у одного пользователя.

Виды

Существуют различные типы ошибок в программах в зависимости от типовых условий использования приложений. Пример – сбои, которые возникают при возрастании нагрузки на оперативную память или центральный процессор устройства. Есть баги граничных условий, сбоя идентификаторов, несовместимости с архитектурой процессора (наиболее распространенная проблема на мобильных устройствах).

Разработчики выделяют следующие типы ошибок по уровню сложности:

1. «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
2. «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
3. «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
4. «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.

Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.

Типы багов

Ошибки в программах бывают:

• логическими;
• синтаксическими;
• взаимодействия;
• компиляционные;
• ресурсные;
• арифметические;
• среды выполнения.

Это – основная классификация сбоев в приложениях и операционных системах. Логические, синтаксические и «среды выполнения» встречаются в разработке чаще остальных. На них будет сделан основной акцент.

Ошибки синтаксиса

Синтаксические баги распространены среди новичков. Они относятся к категории «самых безобидных». С данной категорией ошибок способны справиться компиляторы тех или иных языков. Соответствующие инструменты показывают, где допущена неточность. Остается лишь понять, как исправить ее.

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

Логические сбои обычного типа – самые сложные и неприятные. Их тяжелее всего обнаружить и исправить. С точки зрения языка программа может быть написана идеально, но работать неправильно. Подобное явление – следствие логической ошибки. Компиляторы их не обнаруживают.

Выше – пример логической ошибки в программе. Тут:

1. Происходит сравнение значения i с 15.
2. На экран выводится сообщение, если I = 15.
3. В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

Может показаться, что ошибка безобидная. В приведенном примере так и есть, но в более крупных программах такое явление приводит к серьезным последствиям.

Время выполнения

Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.

Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.

Компиляционный тип

Встречается при разработке на языках высокого уровня. Во время преобразований в машинный тип «что-то идет не так». Причиной служат синтаксические ошибки или сбои непосредственно в компиляторе.

Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.

Ресурсные

Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

Взаимодействие

Подразумевается взаимодействие с аппаратным или программным окружением. Пример – ошибка при использовании веб-протоколов. Это приведет к тому, что облачный сервис не будет нормально функционировать. При постоянном возникновении соответствующей неполадки остается один путь – полностью переписывать «проблемный» участок кода, ответственный за соответствующий баг.

Исключения и как избежать багов

Исключение – событие, при возникновении которых начинается «неправильное» поведение программы. Механизм, необходимый для стабилизации обработки неполадок независимо от типа ПО, платформ и иных условий. Помогают разрабатывать единые концепции ответа на баги со стороны операционной системы или контента.

Исключения бывают:

1. Программными. Они генерируются приложением или ОС.
2. Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

Исключения нужны для охвата критических багов. Избежать неполадок помогут отладчики на этапе разработки. А еще – своевременное поэтапное тестирование программы.

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.

Ошибки в программах – дело обыденное. Приложения зависают, вылетают, перестают запускаться. В простейшем случае пользователь решает проблему переустановкой ПО или чисткой от «мусора». Разработчикам же нужно четко понимать, что такое баг, как исправить его и каким образом получить своевременную обратную связь от пользователей.

Что такое баг?

Термин «баг» (в переводе «жук») у программистов обозначает ситуацию, когда определенный код выдает неверный результат. Причины возникновения разные: ошибки в исходном коде, интерфейсе программы или некорректной работе компилятора. Обнаруживают их на этапе отладки или уже на стадии бета-тестирования, выпуска продукта на рынок.

Варианты ошибок:

1. Появилось сообщение об ошибке, программа продолжает работу.
2. Приложение зависает или вылетает без каких-либо предупреждений.
3. Происходит одно из событий с одновременной отправкой отчета разработчику.

Сложнее всего работать с компьютерными играми, в которых чаще используют термин «краш» (crash). Он означает критическую проблему при запуске или использовании программы. Когда говорят о багах, то чаще имеют в виду сбои графики, например, если игрок «проваливается в текстуры».

Классификация багов

Точка зрения пользователей часто не совпадает с мнением программистов. Так, для первых всего лишь произошел сбой, «приложение перестало работать». Кодеру же предстоит головная боль с определением источника проблемы. Ведь ошибка в программе, вероятно, проявляется лишь на конкретном железе или при сочетании с другим софтом (часто с антивирусами).

Баги делят на категории в зависимости от их критичности:

1. незначительные ошибки,
2. серьезные ошибки,
3. showstopper.

Последние указывают на критическую программную или аппаратную проблему, из-за которой ПО теряет свою функциональность практически на 100%. Например, не удается авторизоваться через логин-пароль или перестала работать кнопка «Далее». Поэтому таким ошибкам отдают приоритет.

Также есть деление ошибок по частоте проявления. Проще всего исправлять постоянные, возникающие при одних и тех же обстоятельствах, независимо от платформы, аппаратной части компьютера или каких-то действий пользователя. Сложность возрастает при периодических сбоях, когда причиной вполне может оказаться глючная оперативная память или ошибки накопителей.

Есть вариант, когда проблема возникает только на машине конкретного клиента. Здесь приходится либо заказывать индивидуальную «работу над ошибками», либо менять компьютер. Потому что ПО для массового пользователя никто не будет редактировать из-за «одного». Только если наберется некая критическая масса одинаковых случаев.

Разновидности ошибок

Программисту еще важно деление на разные типы ошибок приложений исходя из типовых условий их эксплуатации. Например, возникающие при повышении нагрузки на процессор, в интерфейсе, в модуле обработки входящих данных. Существуют баги граничных условий, сбоя идентификаторов, банальной несовместимости с архитектурой процессора (чаще в мобильных устройствах).

Кодеры делят ошибки по сложности:

1. Борбаг (Bohr Bug) – «стабильная» ошибка, легко выявляемая еще на этапе отладки или при бета-тестировании, когда речь еще не идет о выпуске стабильной версии.
2. Гейзенбаг (Heisenbug) – периодически проявляющиеся, иногда надолго исчезающие баги с меняющимися свойствами, включая зависимость от программной среды, «железа».
3. Мандельбаг (Mandelbug) – ошибка с энтропийным поведением, почти с непредсказуемым результатом.
4. Шрединбаг (Schroedinbug) – критические баги, чаще приводящие к появлению возможности взлома, хотя внешне никак себя не проявляют.

Последняя категория ошибок – одна из основных причин регулярного обновления операционных систем Windows. Вроде бы пользователя все устраивает, а разработчик раз за разом выпускает новые пакеты исправлений. Наиболее известный баг, попортивший нервы многим кодерам, это «ошибка 2000 года» (Y2K Error). Про нее успешно забыли, но уроки извлекли.

Программисты различают и те ошибки, что мешают скомпилировать программу, и ворнинги. Вторая категория представляет собой лишь предупреждение о найденных «косяках» в коде, но они не мешают ни сборке ПО, ни последующей эксплуатации. Например, речь идет об отсутствии точки или точки запятой в синтаксисе, когда компилятор способен сам решить проблему.

Логические

Наиболее серьезная из ошибок. Такие баги приводят к изменению функционирования программы вопреки техническому заданию. К чему это приведет, никто не знает – могут записаться на диске «не те данные», некорректно измениться важные документы или предоставиться доступ к коммерческой информации без авторизации. Исправить их получится только при знании изначальной логики.

Синтаксические

Ошибки синтаксиса существуют на уровне конкретного языка программирования: C, Java, Python, Perl и т.д. Что на одной платформе работает максимум с ворнингами, для другой будет серьезной проблемой. Такие баги легко исправить на этапе компиляции, потому что инструмент не позволит «пройти дальше» некорректного участка кода.

Компиляционные

Ситуация происходит, когда код, написанный на языке высокого уровня, преобразуют в «простой», машиночитаемый. Причиной может служить как серьезная ошибка в синтаксисе, так и сбои в самом компиляторе. Такие баги устраняют на этапе разработки-отладки программ, потому что выпустить их даже для бета-тестирования не получится.

Среды выполнения

Так называемые ошибки Run-Time. Проявляются в скомпилированных программах, при запуске. Например, из-за нехватки ресурсов на машине, в результате аварийной ситуации (поломка памяти, носителя, устройств ввода-вывода). Такое происходит, если разработчик не учел реальных условий работы; придется вернуться к стадии проработки логики.

Арифметические

Одна из разновидностей логических ошибок. Происходят, когда программа при работе вычисляет массу переменных, но на каком-то этапе происходит непредвиденное. Например, деление на ноль или же приложение получает «бесконечный» результат. Изменить ситуацию получится только на уровне кода, внедренного в него алгоритма.

Ресурсные

Преимущественно к этой категории относят ошибки типа «переполнение буфера». Программист не учел необходимость очистки памяти перед размещением новых данных. Или интерфейс разработан без учета типовых разрешений экранов, и его элементы постоянно «съезжают», нарушается логика срабатывания кнопок и т.д. Исправить получится только переписыванием части кода.

Взаимодействия

Речь идет о взаимодействии с аппаратным или программным окружением. В случае с приложением для облачного ресурса программист мог допустить ошибку при использовании веб-протоколов. При постоянном появлении ошибки остается только переписывать участок кода, ответственный за появление бага, иначе программа останется неработоспособной.

Что такое исключение

Снизить риски появления непредвиденных ошибок позволяет внедрение в программу исключений. Это события, при возникновении которых начинается «неправильное» поведение. Такой механизм позволяет систематизировать обработку багов независимо от типа приложения, платформы и иных условий. И разработать единую систему реагирования, например, со стороны операционки.

Существуют программные и аппаратные исключения. Первые генерируются самой программой и ОС, под которой она запущена. К аппаратным относятся те, что создаются процессором. Например, деление на 0, переполнение буфера, обращение к невыделенной памяти. Исключениями кодеры охватывают наиболее серьезные, критические баги.

Как избежать ошибок?

Существует два эффективных способа избежать проблем еще на стадии разработки. Первый – это отладка при помощи специальных программ. Они отображают результаты выполнения в цифрах, которые объективно показывают кодеру, правильно ли был обработан следующий участок кода или нужно искать закравшуюся ошибку.

Второй способ представляет собой привлечение специальных людей, тестировщиков. Они помогут разобраться с работоспособностью интерфейса в различных ситуациях, на разных платформах. Это происходит максимально приближенно к реальным условиям. Поэтому любой серьезный продукт проходит такую стадию обязательно.

Выводы

Баги – сопутствующий фактор любой разработки. Большую их часть пользователь не видит, потому что устраняются они еще в «лаборатории», на этапе альфа-тестирования. В бета-версии попадают уже незначительные ошибки, например, связанные с конкретными «узкими» условиями эксплуатации. Редкие проблемы помогают решать краш-репорты – отчеты, отсылаемые производителю самой программой. 

Программная
ошибка
– это расхождение между программой и
её спецификацией, причём тогда и только
тогда, когда спецификация существует
и она правильная.

Программная
ошибка
– это ситуация, когда программа не
делает того, чего пользователь от неё
вполне обоснованно ожидает.

Ошибки
пользовательского интерфейса.
С программой может быть трудно (или даже
невозможно) работать по множеству
причин. Их все можно объединить под
названием “ошибки пользовательского
интерфейса”. Вот несколько разновидностей
таких ошибок.

Функциональность.
Функциональные недостатки имеют место,
если программа не делает того, что
должна, выполняет одну из своих функций
плохо или не полностью. Хотя функции
программы достаточно подробно описываются
в ее спецификации, окончательное
представление о том, что программа
должна делать, существует только в умах
ее пользователей.

Функциональные
недостатки есть абсолютно у всех
программ, поскольку ожидания пользователей
— вещь субъективная: у разных пользователей
они различны. Оправдать их все просто
невозможно, а попытка этого добиться
может привести лишь к усложнению и
потере концептуальной целостности
программного продукта.

Однако
во многих случаях функциональный
недостаток вполне очевиден. Если
предусмотренную программой задачу
трудно выполнить, если она решается
неуклюже или при определенных
обстоятельствах вообще не может быть
решена — проблема налицо. И когда ожидания
пользователей вполне разумны и
обоснованны, эту проблему без колебаний
можно назвать ошибкой.

Взаимодействие
программы с пользователем. Насколько
сложно пользователю разобраться в том,
как работать с программой? Откуда вообще
он об этом узнает? Как обстоит дело с
экранными инструкциями и подсказками?
Достаточно ли их? Понятны ли они? Имеется
ли в программе интерактивная справка
и может ли пользователь в случае
затруднений найти в ней реальную помощь?
Насколько корректно программа сообщает
пользователю о его ошибках и объясняет,
как их исправить? Нет ли в программе
элементов, которые могут раздражать
пользователя, сбивать его с толку или
просто выглядеть неуклюже?

Организация
программы.
Насколько легко потеряться в вашей
программе? Нет ли в ней непонятных команд
или таких, которые легко спутать между
собой? Какие ошибки чаще всего делает
пользователь, на что он тратит больше
всего времени и почему?

Пропущенные
команды.
Чего в программе не хватает? Не заставляет
ли программа выполнять некоторые
действия странным, неестественным или
крайне неэффективным способом? Нельзя
ли привести ее в соответствие с привычным
стилем пользователя? Допускает ли она
хотя бы некоторую степень настройки?

Производительность.
В интерактивном программном обеспечении
очень важна скорость. Плохо, если у
пользователя создается впечатление,
что программа работает медленно, если
он чувствует задержки в ее реакции
(особенно если конкурирующие программы
работают ощутимо быстрее).

Выходные
данные.
Большинство программ так или иначе
формируют выходные данные: отображают
информацию на экране, печатают ее или
сохраняют в файлах. Получаете ли вы то,
что хотите? Правильно ли формируются
отчеты, наглядны ли диаграммы и достаточно
ли отчетливо они выглядят на бумаге?
Сохраняются ли данные в формате, доступном
и для других аналогичных программ?
Обладает ли программа достаточной
гибкостью, чтобы можно было подстраивать
ее под нужды конкретного пользователя?

Обработка
ошибок. Процедуры
обработки ошибок — это очень важная
часть программы. Но, к сожалению, в них
тоже очень часто встречаются ошибки.
Кроме того, правильно определив ошибку,
программа не всегда выдает о ней
достаточно информативное сообщение.

Ошибки,
связанные с обработкой граничных
условий.
Простейшими граничными условиями
являются числовые. Но существует и много
других граничных ситуаций. Любой аспект
работы программы к которому применимы
понятия больше или меньше, раньше или
позже, первый или последний, короче или
длиннее, обязательно должен быть проверен
на границах диапазона. Внутри диапазонов
программа обычно работает прекрасно,
а вот на их границах случаются самые
неожиданные отклонения.

Ошибки
вычислений.
Программирование даже самых простых
арифметических операций чревато
ошибками. Нечего и говорить о сложных
формулах и расчетах. Одними из самых
распространенных среди математических
ошибок являются ошибки округления.
После нескольких промежуточных вычислений
может оказаться, что 2 + 2 = -1, даже если
на промежуточных этапах не было логических
ошибок.

Ошибки
начального и последующих состояний.
Бывает, что при выполнении какой-либо
функции программы сбой происходит
только однажды — при самом первом
обращении к этой функции. Причиной
такого поведения программы может быть
отсутствие файла с инициализационной
информацией. После первого же запуска
программа создаст такой файл, и дальше
все будет в порядке. Получается, что
такую ошибку невозможно повторить
(точнее, для ее повторения нужно установить
новую копию программы). Но не стоит
думать, что ошибка, проявляющаяся только
при первом запуске программы, безвредна:
ведь это будет первое, с чем столкнется
каждый новый пользователь. Иногда,
программируя процесс, связанный с
последовательными преобразованиями
информации, разработчики забывают о
том, что пользователю может понадобиться
вернуться к исходным данным и изменить
их. Насколько корректно поведет себя
программа в такой ситуации? Позволит
ли она внести нужные изменения и не
будет ли из-за этого потеряна вся
выполненная пользователем работа? Что
увидит пользователь при возвращении к
исходному состоянию программы: свои
данные или стандартные значения, которыми
программа инициализирует переменные
при запуске?

Ошибки
передачи или интерпретации данных.
Один модуль может передавать данные
другому или даже другой программе.
Некоторые данные могут передаваться
между модулями множество раз, и на
каком-то этапе они могут быть разрушены
или неверно интерпретированы. Изменения,
внесенные одной из частей программы,
могут потеряться или достичь не всех
частей системы, где они важны.

Ситуация
гонок. Классическая
ситуация гонок описывается так.
Предположим, в системе ожидаются два
события, А и Б. Первым может произойти
любое из них. Но если первым произойдет
событие А, выполнение программы
продолжится, а если первым наступит
событие Б, то в работе программы произойдет
сбой. Программист полагал, что первым
всегда должно быть событие А, и не ожидал,
что Б может выиграть гонки. Тестировать
ситуации гонок довольно сложно. Наиболее
типичны они для систем, где параллельно
выполняются взаимодействующие процессы
и потоки, а также для многопользовательских
систем реального времени. Ошибки в таких
системах трудно воспроизвести, и на их
выявление обычно требуется очень много
времени.

Перегрузки.
Программа может не справляться с
повышенными нагрузками. Например, она
может не выдерживать интенсивной и
длительной эксплуатации или не справляться
со слишком большими объемами данных.
Кроме того, сбои могут происходить из-за
нехватки памяти или отсутствия других
необходимых ресурсов. У каждой программы
свои пределы. Вопрос в том, соответствуют
ли реальные возможности и требования
программы к ресурсам спецификации, и
как программа себя поведет при перегрузках.

Некорректная
работа с аппаратным обеспечением.
Программы могут посылать устройствам
неверные данные, игнорировать сообщения
об ошибках, пытаться использовать
устройства, которые заняты или вообще
отсутствуют. Даже если нужное устройство
просто сломано, программа должна понять
это, а не сбоить при попытке к нему
обратится.

Ошибки
документации.
Сама по себе документация не является
программным обеспечением, но все же это
часть программного продукта. И если она
плохо написана, пользователь может
подумать, что и сама программа не намного
лучше.

Ошибки
тестирования.
Обнаружение ошибок, допущенных
тестировщиками, — дело обычное. Конечно,
если таких ошибок будет слишком много,
вы быстро потеряете доверие остальных
членов команды. Но нужно иметь в виду,
что иногда ошибки тестировщика отражают
проблемы пользовательского интерфейса:
если программа заставляет пользователя
делать ошибки, значит, с ней что-то не
так. Конечно, многие ошибки тестирования
вызваны просто неверными тестовыми
данными.

Характерные
ошибки программирования:

Вид ошибки	Пример
Неправильная постановка задачи	Правильное решение неверно сформулированной задачи
Неверный метод (алгоритм)	Выбор метода (алгоритма) приводящего к неточному или не эффективному решению задач
Логические ошибки	Неполный учет ситуаций, которые могут возникнуть Например, неверное указание ветви алгоритма после проверки некоторого условия, неверное условие выполнения или окончания цикла, неполный учет возможных условий, пропуск в программе одного или более блоков алгоритма.
Семантические ошибки	Непонимание работы оператора
Синтаксические ошибки	Нарушение правил установленных в данном языке программирования Например, неправильная запись формата оператора, повторное использование имени переменной для обозначения другой, ошибочное использование одной переменной вместо другой, несогласованность скобок, пропуск разделителей.
Ошибки времени выполнения	Например, в Delphi, они называются исключениями (exception), как правило, легко устранимы. Они обычно проявляются уже при первых запусках программы и во время тестирования. При возникновении ошибки в программе, запущенной из Delphi, среда разработки прерывает работу программы, и на экране появляется диалоговое окно, которое содержит сообщение об ошибке и информацию о типе (классе) ошибки.

Вопросы
для самопроверки:

1. Дайте
   определение понятия «программная
   ошибка».

2. Перечислите
   источники ошибок
   программного обеспечения.

3. Классифицируйте
   ошибки программного обеспечения.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Что такое ошибка в программировании?

Програ́ммная оши́бка (арго баг от англ. bug — «жук») — означает ошибку в программе или в системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат. Большинство программных ошибок возникают из-за ошибок, допущенных разработчиками программы в её исходном коде, либо в её дизайне.

Как называются ошибки в программировании?

С тех пор, компьютерную ошибку называют багом, а процесс нахождения и исправления ошибок — дебаггингом.

Что называется ошибкой?

Ошибка — это результат действия, совершенного неточно или неправильно, вопреки плану, но самое главное, что результат, который получен, не соответствует с намеченным или заданным, требуемым.

Какие бывают программные ошибки?

Существуют три типа ошибок программирования: — синтаксические ошибки, — ошибки выполнения, — семантические ошибки.

Какие ошибки могут возникнуть при программировании?

Назовите типы ошибок, которые могут возникнуть в программе

Синтаксические ошибки. Runtime errors или ошибки времени выполнения. Логические ошибки.

Какие есть ошибки?

К ним относятся:

• орфографические (ошибки в написании слов);
• грамматические (ошибки в образовании слов и их форм);
• пунктуационные (ошибки в постановке знаков препинания);
• речевые (ошибки в использовании лексики);
• стилистические (ошибки в использовании слов и выражений, не подходящих по стилю);;
• графические (опечатки);

Почему нужно делать ошибки?

Человек, который занимается своим развитием, принимает свои ошибки, берет на себя ответственность за провалы и двигается дальше. Такой человек не только быстрее растет. Он приобретает большее уважение окружающих. Главное, что нам нужно осознать, это что все люди ошибаются и будут ошибаться.

Как называется ошибки и сбой в программе?

В программировании баг (англ. bug — жук) — жаргонное слово, обычно обозначающее ошибку в компьютерной программе или системе, которая выдает неожиданный или неправильный результат.

Как считаются ошибки?

При проверке:

• Негрубые ошибки считаются за пол-ошибки; повторяющиеся ошибки (сколько б их ни было) считаются за одну.
• Первые три однотипные ошибки считаются за одну, каждая следующая подобная ошибка учитывается как самостоятельная.

Что такое техническая ошибка?

Технические ошибки — грамматические и орфографические ошибки, обусловленные неправильным написанием слов, наличием опечаток, погрешностей и другим.

Что такое системные ошибки?

Но если исходить из такого определения (системная ошибка — это цепь решений и действий, приводящих к деградации системы, ее частичному или полному разрушению), то вся образовательная политика последних лет, проводимая в России, — большая системная ошибка.

Каким словом можно заменить слово ошибка?

Синонимы к слову «ошибка» (156 слов)

В чем разница между ошибкой и сбоем?

Ошибка (error): Действие человека, которое приводит к неправильному результату; Дефект (defect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных.

Что легче в программировании?

Если вы хотите выбрать что угодно из программирования, лишь бы это было легко изучить, Python — самый простой язык программирования для новичков. Самым легким для начала будет именно он.

Когда возникает ошибка выполнения программы?

Ошибки при выполнении могут происходить, если работают две несовместимые программы, в случае проблем с памятью компьютера или если компьютер заражен вредоносными программами.

Можно ли исправить ошибку в программе?

Ошибки есть в операционных системах, компиляторах, фреймворках и библиотеках, и ваша программа может быть действительно корректна. Но шансы привлечь внимание разработчика к этим ошибкам невелики, если вы не сможете предоставить подробный алгоритм их воспроизведения.

Кто исправляет ошибки?

Корректор (от лат. corrector — направитель, исправитель) — специалист издательства, типографии или редакции, вычитывающий тексты, исправляющий орфографические, пунктуационные, стилистические ошибки и типографику.

Какие бывают логические ошибки?

Виды логических ошибок:

• Формальные ошибки
• Использование ложных и недоказанных аргументов, утверждений
• Особые случаи
• Мнимая логическая связь
• Доказательство через то же самое
• Приписывание утверждений
• Использование принципиально неопровержимых утверждений
• Ложная аналогия

Как называется ошибка в букве?

Опеча́тка — ошибка в печатном тексте, обычно возникает в результате случайности. Чаще всего в результате опечатки нарушается порядок букв в слове (быьт вместо быть), одна буква исчезает из слова (чловек вместо человек), добавляется лишняя буква (лампва вместо лампа) или заменяется другой (конб вместо конь).

Как называются ошибки и сбои в программе?

Програ́ммная оши́бка (арго баг от англ. bug — «жук») — означает ошибку в программе или в системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат. Большинство программных ошибок возникают из-за ошибок, допущенных разработчиками программы в её исходном коде, либо в её дизайне.

Как называется исправление ошибок?

Корректор (от лат. corrector — направитель, исправитель) — специалист издательства, типографии или редакции, вычитывающий тексты, исправляющий орфографические, пунктуационные, стилистические ошибки и типографику.

Как называется специальные ошибки?

Эррати́в (от лат. errare в значении «ошибаться») или какогра́фия (от др. -греч. κακός — плохой и γράφω — пишу) — слово или выражение, подвергнутое умышленному искажению носителем языка, владеющим литературной нормой, для придания особого эффекта.

Как называются пунктуационные ошибки?

Пунктуационная ошибка — это неиспользование пишущим необходимого знака препинания или его употребление там, где он не требуется, а также необоснованная замена одного знака препинания другим.

Ответить

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.

Обработка ошибок в Node.js

По мере освоения Node.js можно достаточно долго писать программы, не уделяя при этом должного внимания корректной обработке ошибок. Однако, разработка серьёзных проектов на Node.js требует осознанного подхода к этой проблеме.

У начинающих разработчиков часто возникают следующие вопросы:

Данная статья состоит из семи частей:

1. Введение. О том, что читатель должен знать перед ознакомлением со статьей.
2. Программные ошибки и ошибки программиста. Ознакомление с типами ошибок.
3. Шаблоны написания функций. Основополагающие принципы написания функций, реализующих корректную работу с ошибками.
4. Правила написания функций. Перечень указаний которым следует придерживаться при написании функций.
5. Пример. Пример написания функции.
6. Резюме. Краткое представление основных положений рассмотренных в статье.
7. Приложение. Общепринятые имена полей объектов ошибок.

1. Введение

Предполагается, что читатель:

• знаком с термином «исключение» в JavaScript, Java, Python, C++, или другом подобном языке и понимает принцип работы конструкции try/catch;
• знаком с разработкой на Node.js и освоил принципы асинхронного программирования.

Читатель должен понимать, почему в представленном ниже коде не работает перехват исключений, несмотря на наличие конструкции try/catch.¹

function myFunc(callback)
{
  /*
   * Пример некорректного перехвата исключений
   */
  try {
    doSomeAsyncOperation(function (err) {
      if (err) {
        throw (err);
      }
    });
  } catch (ex) {
    callback(ex);
  }
}

Читателю следует знать, что в Node.js существует 3 основных способа, которыми функция может вернуть ошибку:

1. Бросание ошибки throw (генерирование исключения).
2. Вызов callback-функции с объектом ошибки в качестве первого аргумента.
3. Генерирование события 'error' у объекта класса EventEmitter.

Предполагается, что читатель не знаком с доменами в Node.js.

Читатель должен понимать разницу между ошибкой и исключением в JavaScript. Ошибка — это любой объект класса Error. Ошибка может быть создана конструктором класса и возвращена из функции либо брошена с помощью инструкции ThrowStatement. Когда объект ошибки брошен, возникает исключение. Далее приведён пример бросания ошибки (генерирование исключения):²

throw new Error('произошла ошибка');

Пример, где ошибка передаётся в callback-функцию:

callback(new Error('произошла ошибка'));

Второй вариант чаще встречается в Node.js, из-за асинхронности большинства выполняемых операций. Как правило, первый вариант используется лишь при десериализации данных (например, JSON.parse), при этом брошенное исключение перехватывается с помощью конструкции try/catch. Это отличает Node.js от Java или C++ и других языков, где приходится чаще работать с исключениями.

2. Программные ошибки и ошибки программиста

Ошибки можно условно разделить на два типа:³

• Программные ошибки представляют собой конфликты, возникающие в ходе нормального функционирования программы. Они не являются «багами». Обычно, они не связаны напрямую с программой: системные ошибки (например, переполнение памяти), ошибки конфигураций (например, неверно указан адрес удалённого сервера), ошибки интернет-соединения или ошибки возникшие на удалённом сервере.
  Примеры программных ошибок:
  • пользователь ввёл некорректные данные,
  • истекло время ожидания ответа на запрос (request timeout),
  • сервер ответил на запрос ошибкой с кодом 500,
  • разрыв соединения,
  • израсходована выделенная память.

• Ошибки программиста — это дефекты кода, приводящие к некорректной работе программы. Ошибки данного типа не могут быть правильно обработаны, так как сам факт их наличия говорит о некорректности написанного кода. Ошибки этого типа возможно устранить изменив код программы. К ошибкам программиста можно отнести:
  • попытку обратиться к какому-либо полю у значения undefined,
  • вызов асинхронной функции без callback-функции,
  • вызов функции с некорректными аргументами.

Разработчики используют термин «ошибка» для обоих типов ошибок, несмотря на их принципиальные различия. «Файл не найден» — программная ошибка, её возникновение может означать, что программе требуется создать искомый файл. Таким образом, возникновение этой ошибки не является некорректным поведением программы. Ошибки программиста, напротив, не предполагались разработчиком. Возможно, разработчик ошибся в имени переменной или неправильно описал проверку данных, введённых пользователем. Данный тип ошибок не поддается обработке.

Возможны случаи, когда по одной и той же причине возникают как программная ошибка, так и ошибка программиста. Предположим, HTTP-сервер производит попытку считать какое-либо поле у значения undefined, что является ошибкой программиста. В результате, сервер выходит из строя. Клиент, при этом, в качестве ответа на свой запрос получает ошибку ECONNRESET, обычно описываемую Node.js как: «socket hang-up». Для клиента, это программная ошибка и корректно написанная программа-клиент соответствующим образом обработает ошибку и продолжит работу.

Отсутствие обработчика программной ошибки является ошибкой программиста. Предположим, что программа-клиент, устанавливая соединение с сервером, сталкивается с ECONNREFUSED ошибкой, в результате, объект соединения генерирует событие 'error', но для данного события не зарегистрирована ни одна функция-обработчик, по этой причине программа выходит из строя. В данном случае, ошибка соединения является программной ошибкой, однако, отсутствие обработчика для события ‘error’ объекта соединения — ошибка программиста.

Важно понимать различия между ошибками программиста и программными ошибками. Поэтому, прежде чем продолжать чтение статьи, убедитесь, что вы разобрались в этих понятиях.

Обработка программных ошибок

Обработка программных ошибок, так же как и вопросы безопасности или производительности приложения, не относится к тому типу задач, которые могут быть решены внедрением какого-либо модуля — невозможно в одном месте исходного кода решить все проблемы связанные с обработкой ошибок. Для решения задачи обработки ошибок требуется децентрализованный подход. Для всех участков программы, где возможно возникновение ошибки (обращение к файловой системе, соединение с удалённым сервером, создание дочернего процесса и т.д.) необходимо предписать соответствующие сценарии обработки для каждого возможного типа ошибки. Значит, необходимо не только выделить проблемные участки, но и понять каких типов ошибки могут в них возникнуть.

В некоторых случаях приходится передавать объект ошибки из функции, в которой она возникла, через callback-функцию на уровень выше, а из него еще выше, таким образом ошибка «всплывает» до тех пор, пока не достигнет логического уровня приложения, который ответственен за обработку данного типа ошибок. На ответственном уровне программа может принять решение: запустить ли проблемную операцию повторно, сообщить ли об ошибке пользователю или записать информацию об ошибке в лог-файл и пр. Не следует всегда полагаться на эту схему и передавать ошибки более высоким уровням иерархии, так как callback-функции на высоких уровнях ничего не знают о том, в каком контексте возникла переданная им ошибка. В результате, может возникнуть ситуация, когда на выбранном логическом уровне будет сложно описать логику обработки, соответствующую возникшей ошибке.

Выделим возможные сценарии обработки ошибок:

• Устранение ошибки. Иногда, возникшую ошибку можно устранить. Предположим, возникла ошибка ENOENT, при попытке записать информацию в лог-файл. Это может означать, что программа запущена впервые и лог-файл еще не создан. В таком случае, обработчик может устранить ошибку, создав искомый файл. Приведём более интересный пример: программе необходимо постоянно поддерживать соединение с определённым севером (например, с базой данных), но в ходе работы возник разрыв соединения. В этом случае обработчик ошибки может произвести переподключение к базе данных.
• Информирование пользователя и прекращение обработки запроса. Если нельзя решить возникшую проблему, проще всего прервать работу текущей операции, и сообщить пользователю об ошибке. Данный сценарий применим в случаях, когда известно, что причина, по которой возникла ошибка, не исчезнет с течением времени. К примеру, если ошибка возникла при попытке десериализации JSON-данных, переданных клиентом, то нет смысла повторять попытку с этими же данными.
• Повторение операции. В случае ошибок связанных с работой по сети может помочь повторный запуск операции. Предположим, программа в ответ на запрос к удалённому сервису получила в ответе ошибку 503 (Service Unavailable error), в таком случае, возможно, стоит повторить запрос спустя несколько секунд. Важно определить конечное число повторов, а так же, с какой периодичностью должны выполняться попытки. Но не следует всегда полагаться на данный сценарий. Предположим, пользователь выполнил запрос к некоторому сервису, которому для обработки запроса потребовалось обратиться к вашей программе, а ваша программа, в свою очередь, осуществляет запрос к еще одному сервису, который ответил ошибкой 503. В этом случае, лучшим решением будет не выполнять повторных попыток, а незамедлительно дать возможность обработать ошибку исходному сервису, с которым работает пользователь. Если каждый сервис, участвующий в цепочке запросов, будет производить повторные попытки, то пользователь будет ожидать ответ на свой запрос дольше чем, если бы их выполнял только исходный сервис.
• Прекращение работы программы. Если произошла непредвиденная ситуация, появление которой невозможно при нормальном функционировании программы, следует записать информацию об ошибке в соответствующий лог-файл и прекратить работу. Данный сценарий может быть использован, если ваша программа израсходовала доступную память (однако, если ваша программа получила ошибку ENOMEM от дочернего процесса, то ошибку можно обработать и не прекращать работу программы). Так же, данный сценарий можно применить если у вашей программы нет прав доступа к необходимым для работы файлам.
• Запись ошибки в лог-файл и продолжение работы. В некоторых случаях нет необходимости прекращать работу программы даже если возникшая ошибка неустранима. В пример можно привести ситуацию, когда ваша программа периодически обращается к группе удалённых сервисов через систему DNS, и один из сервисов «выпал» из DNS. В данной ситуации программа может продолжить работу с оставшимися сервисами. Но, тем не менее, необходимо записать об ошибке в лог-файл. (Для любого правила всегда есть исключения, если ошибка возникает тысячу раз в секунду, и вы не можете ничего с ней поделать, то не нужно каждый раз выполнять запись в лог, однако, стоит периодически производить логирвоание.)

Обработка ошибок программиста

Не существует правильного способа обрабатывать ошибки программиста. По определению, если возникла такая ошибка, то код программы некорректен. Устранить проблему можно лишь исправив код.

Есть программисты считающие, что в некоторых случаях можно восстанавливать программу после произошедшей ошибки таким образом, что текущая операция прерывается, но программа, тем не менее, продолжает работать и обрабатывать другие запросы. Так поступать не рекомендуется. Принимая во внимание то, что ошибка программиста вводит программу в нестабильное состояние, можете ли вы быть уверены в том, что возникшая ошибка не нарушит работу других запросов? Если запросы работают с одними и теми же сущностями (например, сервер, сокет, соединения с базой данных и т.д.), остаётся лишь надеется, что последующие запросы будут правильно обработаны.

Рассмотрим REST-сервис (реализованный, например, с помощью модуля restify). Предположим, что один из обработчиков запросов бросил исключение RefferenceError из-за того, что программист сделал опечатку в имени переменной. Если немедленно не прекратить работу сервиса, может возникнуть ряд проблем, которые бывает сложно отследить:

• Если какая-то сущность в результате опечатки оказалась равна null или undefined, то последующие запросы, обратившись к ней, так же, бросят исключения и не будут обработаны.
• Если функция, которая бросила исключение, работала с базой данных, может произойти утечка соединия. Каждый раз, когда подобная ошибка будет повторяться, число соединений, используя которые сервис может работать с базой данных, будет уменьшаться.
• Более сложная ситуация может произойти, если в качестве базы данных используется postgres, и соединение осталось незакрытым в ходе выполнения транзакции. В этом случае, «повисшая» транзакция не даст очищать старые версии записей, которые для неё видны. Транзакция может оставаться открытой неделями. Размер, который таблица занимает в памяти, будет расти без ограничений, что приведёт к тому, что обработка последующих запросов будет замедляться.⁴ Конечно, данный пример достаточно специфичен и касается лишь postgres, однако, он отлично иллюстрирует, что опасно продолжать работу программы, которая пребывает в нестабильном состоянии.
• Соединение к удалённому сервису может остаться с незакрытой сессией, вследствие чего, следующий запрос может быть обработан от лица не того пользователя.
• Может остаться незакрытым сокет. По умолчанию Node.js закроет неактивный сокет через две минуты, но это поведение может быть переопределено, и если ошибка будет повторяться, то в итоге число возможных сокетов будет исчерпано. Если вы оставите конфигурации по умолчанию, отследить и исправить проблему будет тяжело, так как ошибка о неактивном сокете возникает с задержкой в две минуты.
• Может возникнуть утечка памяти, которая приведёт к её переполнению и выходу программы из строя. Или еще хуже — утечка может усложнить процесс сборки мусора, из-за чего начнет страдать производительность программы. Обнаружить причину проблемы в таком случае будет особенно затруднительно.

Учитывая вышеперечисленное, в таких ситуациях лучшим решением будет прервать работу программы. Вы можете перезапускать свою программу, после того как она была прервана — такой подход позволит автоматически восстанавливать стабильную работу вашего сервиса после возникающих ошибок.
Единственный, но существенный, недостаток этого подхода заключается в том, что будут отключены все пользователи работавшие с сервисом в момент перезапуска. Имейте ввиду следующее:

• Сбои вызванные ошибкой программиста вводят приложение в нестабильное состояние. Нужно стремиться к тому, чтобы таких ошибок не возникало, их устранение имеет наивысший приоритет.
• После перезапуска запросы могут как выполняться корректно, так и снова привести к ошибке. Может случиться так, что запросы обрабатываются некорректно, но отследить проблему сложно.
• В хорошо спроектированной системе, независимо от того вызвана ли ошибка проблемой с интернет-соединением или ошибка произошла в Node.js, программа-клиент должна уметь обрабатывать ошибки сервера (переподключаться, выполнять повторные запросы).

Если перезапуск программы происходит очень часто, то следует отлаживать код и устранять ошибки. Лучшим способом для отладки будет сохранение и анализ снимка ядра. Данный подход работает как в GNU/Linux-системах, так и в illumos-системах, и позволяет просмотреть не только последовательность функций, которые привели к ошибке, но и переданные им аргументы, а так же состояние других объектов, видимых через замыкания.

3. Шаблоны написания функций

Во-первых стоит отметить, что очень важно подробно документировать свои функции. Необходимо описывать, что возвращает функция, какие аргументы принимает и какие ошибки могут возникнуть в процессе выполнения функции. Если не определить типы возможных ошибок и не сформулировать, что они означают, то вы не сможете правильно написать обработчик.

Throw, callback или EventEmitter?

Существует три основных способа вернуть ошибку из функции:

1. throw возвращает ошибку синхронно. Это значит, что исключение возникнет в том же контексте, в котором функция была вызвана. Если используется try/catch, то исключение будет поймано. В противном случае — программа выйдет из строя (если, конечно, исключение не отловит домен или обработчик события 'uncaughtException' глобального объекта process, такой вариант будет рассмотрен далее).
2. Вызов callback-функции с объектом ошибки в качестве первого аргумента является наиболее часто используемым способом вернуть ошибку из асинхронной функции. Общепринятым шаблоном вызова callback-функции является вызов вида callback(err, results), где только один из аргументов может принимать значения отличные от null.
3. В более сложных случаях функция может генерировать событие 'error' объекта класса EventEmitter, тогда ошибка будет обработана, если зарегистрирован обработчик для события 'error'. Данный вариант используется если:
   • производится комплексная операция, которая возвращает несколько результатов или ошибок. Примером может быть извлечение записей из базы данных. Функция возвращает объект класса EventEmitter и вызывает событие 'row' — при извлечении каждой записи, "end" — когда все записи извлечены и 'error' — если возникает ошибка.
   • объект представляет собой сложный автомат, производящий множество асинхронных операций. В пример можно привести сокет, вызывающий события 'connect', 'end', 'timeout', 'drain' и 'close'. При возникновении ошибки, объект будет генерировать событие 'error'. Используя данный подход важно понимать, в каких ситуациях может возникать ошибка, могут ли при этом возникать и другие события и в каком порядке они возникают.

Использование callback-функций и генерирование событий относятся к асинхронным способам возврата ошибок. Если производится асинхронная операция, то реализуется один из этих способов, но никогда не используются сразу оба.

Итак, когда же использовать throw, а когда использовать callback-функции или события? Это зависит от двух факторов:

• типа ошибки (ошибка программиста или программная ошибка),
• типа функции в которой возникла ошибка (асинхронная или синхронная).

Программные ошибки характерны в большей мере для асинхронных функций. Асинхронные функции принимают в качестве аргумента callback-функцию, при возникновении ошибки она вызвается с объектом ошибки в качестве аргумента. Такой подход отлично себя зарекомендовал и широко применяется. В качестве примера можно ознакомиться с Node.js модулем fs. Событийный подход так же используется, но уже в более сложных случаях.

Программные ошибки в синхронных функциях могут возникать, как правило, если функция работает с данными, введёнными пользователем (например JSON.parse). В таких функциях при возникновении ошибки бросается исключение, реже – объект ошибки возвращается оператором return.

Если в функции хотя бы одна из возможных ошибок асинхронна, то все возможные ошибки должны возвращаться из функции используя асинхронный подход. Даже если ошибка возникла в том же контексте, в котором была вызвана функция, объект ошибки следует вернуть асинхронно.

Есть важное правило: для возврата ошибок в одной и той же функции может быть реализован либо синхронный, либо асинхронный подход, но никогда и тот и другой вместе. Тогда, чтобы принимать у функции ошибку, нужно будет использовать либо callback-функцию (или функцию-обработчик события 'error'), либо конструкцию try/catch, но никогда и то и другое. В документации к функции следует указывать, какой из способов к ней применим.

Проверка входных аргументов как правило позволяет, предупредить многие ошибки, которые совершают программисты. Часто случается, что при вызове асинхронной функции, ей забывают передать callback-функцию, в результате, чтобы понять где возникает ошибка, разработчику приходится, как минимум, просмотреть стек вызванных функций. Поэтому, если функция асинхронна, то в первую очередь, важно проверять передана ли callback-функция. Если не передана, то необходимо генерировать исключение. Кроме того, в начале функции следует проверять типы переданных ей аргументов, и так же генерировать исключение, если если они некорректны.

Напомним, что ошибки программиста не являются частью нормального процесса работы программы. Они не должны отлавливаться и обрабатываться. Поэтому данные рекомендации о немедленном бросании исключений при ошибках программиста не противоречат сформулированному выше правилу о том, что одна и та же функция не должна реализовывать как синхронный так и асинхронный подход для возврата ошибок.

Рассмотренные рекомендации представлены в таблице:

В первой записи представлен наиболее часто встречаемый пример — асинхронная функция. Во второй строке – пример для синхронной функции, такой вариант встречается реже. В третей строке — ошибка программиста, желательно, чтобы подобные случаи имели место лишь в процессе разработки программы.

Ошибка ввода: ошибка программиста или программная ошибка?

Как различать ошибки программиста от программных ошибок? Вам решать, какие данные переданные функции являются корректными, а какие – нет. Если в функцию переданы аргументы не отвечающие поставленным вами требованиям, то это ошибка программиста. Если же аргументы корректны, но функция в данный момент не может с ними работать, то это программная ошибка.

Вам предстоит решать с какой строгостью производить проверку аргументов. Представим некую функцию connect, котороя принимает IP-адрес и callback-функцию в качестве аргументов. Предположим, что был произведён вызов этой функции с аргументом отличающимся по формату от IP-адреса, например: «bob». Рассмотрим что может произойти в таком случае:

• Если вы строго производите проверку, соответствует ли формат введённой строки формату IPv4 адреса, то ваша функция бросит исключение на этапе проверки аргументов. Такой сценарий является наиболее приемлимым.
• Если же вы проверяете лишь тип аргументов, то возникнет асинхронная ошибка о том, что невозможно подключиться к IP-адресу «bob».

Оба варианта удовлетворяют рассмотренным рекомендациям и вам решать насколько строго производить проверку. Функция Date.parse, например, принимает аргументы различных форматов, но на то есть причины. Всё же, для большинства функций рекомендуется строго проверять переданные аргументы. Чем более расплывчаты критерии проверки аргументов, тем более затруднительным становится процесс отладки кода. Как правило, чем строже проверка – тем лучше. И даже если в будущих версиях программы вы вдруг смягчите критерии проверки внутри какой-то функции, то вы не рискуете сломать ваш код.

Если переданное значение не удовлетворяет требованиям (например, undefined или строка имеет неверный формат), то функция должна сообщать о том, что переданное значение некорректно и прекращать работу программы. Прекращая работу программы, сообщив о некорректных аргументах, вы упрощаете процесс отладки кода себе и другим программистам.

Домены и process.on(‘uncaughtException’)

Программные ошибки всегда могут быть отловлены по определённому механизму: через try/catch, в callback-функции или обработчиком события 'error'. Домены и событие глобального объекта process 'uncaughtException' часто используются для перестраховки от непредвиденных ошибок, которые мог допустить программист. Учитывая рассмотренные выше положения, данный подход настоятельно не рекомендуется.

4. Правила написания функций

При написании функций придерживайтесь следующих правил:

1. Пишите подробную документацию
   Это самое важное правило. Документация к функции должна содержать информацию:
   • о том с какими аргументами работает функция;
   • о том каких типов должны быть аргументы;
   • о любых дополнительных ограничениях, которые накладываются на вид аргументов (пример: IP-адрес должен иметь корректный формат).

   Если какое-то из установленных правил не выполняется, то функция должа немедленно бросать исключение.
   Так же следует документировать:

   • какие программные ошибки могут возникнуть в ходе выполнения функции (включая имена ошибок),
   • как обрабатывать возможные ошибки (отлавливать через try/catch или использовать асинхронные подходы),
   • описание результата выполнения функции.

2. Используйте объекты класса Error (или подклассов) для всех ошибок.
   Все ваши ошибки должны быть объектами класса Error или классов, которые являются его наследниками. Используйте поля name и message, поле stack так же должно корректно работать.
3. Расширяйте объект ошибки полями, которые описывают подробности ошибки.
   Если в функцию был передан некорректный аргумент, задайте в объекте ошибки поля propertyName и propertyValue. Для ошибок подключения к удалённому серверу расширяйте объект ошибки полем remoteIp, чтобы указать к какому адресу не удалось подключиться. При возникновении системной ошибки включайте в объект ошибки поле syscall, поясняющее, какой системный вызов не был обработан, так же включите поле errno , содержащее информацию о типе системной ошибки. В приложении к статье описаны рекомендуемые имена полей.

   Ошибка обязательно должна содержать корректные поля:

   • name: используется обработчиками для дифференциации ошибок по типу.
   • message: текст описывающий возникшую проблему. Текст должен быть коротким, но достаточно ёмким, что бы можно было понять суть проблемы.
   • stack: никогда не изменяйте объект стэка вызовов. V8 производит построение этого объекта только тогда, когда к нему производится обращение и процесс построения достаточно ресурсоёмкий, обращение к этому полю существенно снижает производительность программы.

   Ошибка должна содержать достаточно информации, чтобы обработчик мог на её основе сформировать своё сообщение об ошибке, не используя при этом поле message исходной ошибки. Возможно обработчику потребуется формировать ошибку из нескольких, чтобы выводить их в форме таблицы конечному пользователю.

4. Если ошибка возвращается с низкого уровня вложенности функций, то следует оборачивать её.
   В начале статьи упоминалось, что возможна ситуация, когда приходится возвращать ошибку из функции, в которой она возникла через callback-функцию на уровень выше, а затем еще выше, до тех пор пока она не достигнет логического уровня приложения, который ответственен за обработку данного типа ошибок. В таких случаях рекомендуется производить обёртку ошибки по мере её «всплытия». Обёрткой функции называется расширение исходного объекта ошибки информацией о логическом уровне через который она была передана. Модуль verror позволяет реализовать такой механизм.
   Рассмотрим некую функцию fetchConfig, извлекающую настройки из удалённой базы данных. Вызов fetchConfig выполняется при старте работы сервиса. Алгоритм работы функции описан ниже.

       1. Извлечение настроек
         1.1 Соединение с базой данных
           1.1.1 Получение адреса через систему DNS
           1.1.2 Создание TCP соединения с сервером базы данных
           1.1.3 Аутентификация на сервере базы данных
         1.2. Выполнение запроса к базе данных
         1.3. Обработка результата запроса
         1.4. Настройка сервиса
       2. Запуск работы сервиса
       

   Предположим, что в пункте 1.1.2 возникла ошибка. Если передавать ошибку в контекст из которого была вызвана функция fetchConfig не оборачивая её, то сообщение об ошибке будет иметь вид:

   myserver: Error: connect ECONNREFUSED
   

   Пользы от такого сообщения мало.
   Далее представлено сообщение о той же ошибке, но с применением обёртки:

   myserver: failed to start up: failed to load configuration: failed to connect to
   database server: failed to connect to 127.0.0.1 port 1234: connect ECONNREFUSED
   

   Если не выполнять обёртку на некоторых уровнях, то можно получить более лаконичное сообщение:

   myserver: failed to load configuration: connection refused from database at
   127.0.0.1 port 1234.
   

   Однако, как правило, избыток информации — лучше чем дефицит.

   Есть несколько нюансов о которых нужно знать, если вы решили оборачивать свои ошибки:

   • Старайтесь не изменять поля начального обьекта ошибки, обработчику может потребоваться информация об исходной ошибке.
   • Поле name ошибки при обёртке можно изменять, чтобы оно больше соответствовало контексту. Однако, нет необходимости это делать, если у объекта ошибки есть иные поля, по которым обработчик может распознать её тип.
   • Поле message при обёртке тоже может быть изменено, но не следует при этом менять message исходного объекта. Не производите никаких действий с полем stack, как уже упоминалось выше, V8 формирует объект stack, только при обращении к нему и это достаточно ресурсоёмкий процесс, который может привести к существенному снижению производительности вашей программы.

   В Joyent мы используем модуль verror для обёртки ошибок, так как он имеет минималистичный синтаксис. На момент написания статьи в модуле не реализованы некоторые из рассмотренных рекомендаций, однако он будет дорабатываться.

5. Пример

Рассмотрим в качестве примера функцию, которая создаёт TCP соединение по указанному IPv4 адресу.

/*
 * Функция создаёт TCP соединение по указанному IPv4 адресу.  Аргументы:
 *
 *    ip4addr        строка адреса формата IPv4;
 *
 *    tcpPort        натуральное число, TCP порт;
 *
 *    timeout        натуральное число, время в миллисекундах, в течение которого
 *                   необходимо ждать ответа от удалённого сервера;
 *
 *    callback       функция вызываемая после завершения операции,
 *                   если операция завершилась успешно, происходит 
 *                   вызов вида callback(null, socket), где socket это
 *                   объект класса net.Socket, если возникла ошибка,
 *                   выполняется вызов вида callback(err).
 *
 * В функции могут возникнуть ошибки следующих типов:
 *
 *    SystemError    Для "connection refused", "host unreachable" и других
 *                   ошибок, возвращаемых системным вызовом connect(2). Для
 *                   данного типа ошибок поле errno объекта err будет содержать
 *                   соответствующее ошибке символьное представление.
 *
 *    TimeoutError   Данный тип ошибок возникает при истечении 
 *                   времени ожидания timeout.
 *
 * Все возвращаемые объекты ошибок имеют поля "remoteIp" и "remotePort".
 * После возникновении ошибки, сокеты, которые были открыты функцией, будут закрыты.
 */
function connect(ip4addr, tcpPort, timeout, callback)
{
  assert.equal(typeof (ip4addr), 'string',
      "аргумент 'ip4addr' должен быть строкового типа");
  assert.ok(net.isIPv4(ip4addr),
      "аргумент 'ip4addr' должен содержать IPv4 адрес");
  assert.equal(typeof (tcpPort), 'number',
      "аргумент 'tcpPort' должен быть числового типа");
  assert.ok(!isNaN(tcpPort) && tcpPort > 0 && tcpPort < 65536,
      "аргумент 'tcpPort' должен быть натуральным числом в диапазоне от 1 до 65535");
  assert.equal(typeof (timeout), 'number',
      "аргумент 'timeout' должен быть числового типа");
  assert.ok(!isNaN(timeout) && timeout > 0,
      "аргумент 'timeout' должен быть натуральным числом");
  assert.equal(typeof (callback), 'function');

  /* код функции */
}

Этот пример достаточно примитивен, но он иллюстрирует многие из рассмотренных рекомендаций:

• Аргументы, их типы, и предъявляемые к ним требования подробно документированы.
• Функция проверяет переданные ей аргументы и бросает исключение, если аргументы не удовлетворяют критериям.
• Документированы типы возможных ошибок, а так же поля, которые они содержат.
• Указан способ, которым функция возвращает ошибки.
• Возвращаемые ошибки имеют поля «remoteIp» и «remotePort», что позволит обработчику на основе этой информации формировать сообщение ошибки.
• Документировано состояние соединений после возникновения ошибки: «после возникновении ошибки, сокеты которые были открыты функцией, будут закрыты».

Может показаться, что в представленном примере проделано много лишней работы, однако, десять минут потраченные на опиание документации могут сэкономить несколько часов вам или другим разработчикам.

6. Резюме

• Различайте ошибки программиста и программные ошибки.
• Програмные ошибки могут и должны обрабатываться, тогда как ошибки программиста не могут быть корректно обработаны. Не следует продолжать работу программы в случае возникновения ошибок программиста, так как дальнейшее поведение программы непредсказуемо.
• Для возврата ошибок в функции может быть реализован синхронный подход (например, throw) или асинхронный подход (callback-функция или событие), но нельзя реализовывать оба подхода в одной функции. Тогда, при использовании функции, чтобы обрабатывать возникающие в ней ошибки, нужно будет применять либо callback-функции, либо конструкцию try/catch, но никогда и то и другое.
• При написании функций подробно документируйте аргументы, их типы, предъявляемые к ним требования, а так же типы возможных ошибок и то, как функция возвращает ошибки (синхронно, используя throw, или асинхронно, используя callback-функцию или событийный подход).
• Возвращаемая ошибка должна быть объектом класса Error или класса-наследника. Расширяйте объект ошибки новыми полями, чтобы включить в объект необходимую информацию об ошибке. По возможности используйте общепринятые имена полей, представленные в приложении.

7. Приложение: общепринятые имена полей ошибок

Настоятельно рекомендуется для расширения объектов ошибок использовать приведённые в таблице имена полей. Представленные имена используются в стандартных модулях Node.js, следует пользоваться ими в обработчиках ошибок, а так же при формировании сообщений об ошибках.

¹ Начинающие разработчики часто допускают подобную ошибку. В данном примере try/catch и вызов функции бросающей исключение выполнятся в разных контекстах из-за асинхронности функции doSomeAsyncOperation, поэтому исключение не будет поймано.
² В JavaScript throw может работать со значениями и других типов, но рекомендуется использовать именно объекты класса Error. Если в ThrowStatement использовать другие значения, то будет невозможно получить стэк вызовов, который привел к ошибке, что усложнит отладку кода.
³ Данные понятия возникли задолго до появления Node.js. В Java аналогом можно считать проверяемые и непроверяемые исключения. В C для работы с ошибками программиста предусмотрены утверждения.
⁴ Приведённый пример может показаться слишком предметным, это потому, что он не вымышлен, мы действительно сталкивались с этой проблемой, это было неприятно.