Return to Data Taxonomy

Return to Top

There are all kinds of errors that can occur in Systems and Applications. Some errors are more or less static in nature and must be addressed before the software can be released. Others can occur during the running of the System or Application. Some of these errors are the result of aborent use of resources such as Out of Memory or Dividion by Zero while others are the result the code not doing what it is intended auch as Invalid Data.

• Syntax Errors
• Runtime Errors
• Logic Errors

Return to Top

A Syntax Errors are errors in program or script Source Code not meeting (following), or deviating from the standardized Syntax associated with the Programming Language.

Syntax Errors are generally small grammatical mistakes in the Source Code and can seem as trivial as a single character (i.e., a missing semicolon, or quotations, parenthesis, braces, or brackets not balanced). In the C++ code below, there is a Syntax Error on each line. The errors are indicated by comments on the line:

#include <iostream>
using namespace std;
 
void main()
{ int x = 10                     // semicolon missed
  int y = 15.4;                  // Asigning an int with a floating point number
  char delimeter = ",";          // Using a quotation mark instead of an apostrophy for a character
  string myText = 'hello World'; // Using apostrophe instead of a quotation Mark
  cout << " "<< meText;          // referencing a variable that is not declared
} }                              // Too many closing braces

Some software Integrated Development Environments (IDEs) check Source Code for Syntax Errors in real-time, while others only generate syntax errors when a program is compiled. Even if a source code file contains one small syntax error, it will prevent an application from being successfully compiled and deployed. Similarly, if you run a script through an interpreter, any Syntax Errors will prevent the script from completing. In most cases, the compiler or interpreter provides the location (or line number) of the Syntax Error, making it easy for the programmer to find and fix the error.

As a general rule, Strongly Typed Languages create more Syntax Errors than Weakly Typed Languages with the idea that these Syntax Errors help prevent harder to diagnose Runtime Errors or Logic Errors.

Return to Top

Solidity Syntax errors are detected within Syntax Highlighting the remix or other Integrated Development Environments (IDEs) such as Microsoft: Visual Studio Code (VS Code) with the Solidity Plug In.

A very important aspect of Syntax Errors caught within the IDE is that these errors are NOT caught on the blockchain, but rather just inside the IDE. This means there is no expenditure of Gas to catch these errors.

Return to Top

Runtime Errors refer to a class of errors occurring during the execution of a program or an Application. Runtime errors imply Bugs in the running code developers expected but were unable to correct. For example, when the Application can not allocate more memory, an Out of Memory is triggered, terminating the Application and resulting in a Core Dump. The Core Dump and a Debugger are some of the most powerful and useful tools in tracking down Runtime Errors.

There are always costs associated with Runtime Errors and many of these errors can be traced to poor specification of reqiurements, misuderstanding of what the requirements are, or ignorance of the requirements.

Many studies have shown that requirements errors are very costly. By one estimate (in an article by Donald Firesmith for the Software Engineering Institute), requirements errors cost US businesses more than $30 billion per year and often result in failed or abandoned projects and damaged careers. The common wisdom is to find and fix requirements errors early in the lifecycle of a project, but that is easier said than done. Furthermore, the actual cost of a requirement error has been hard to quantify in the past. This resulted in a “business-as-usual” approach rather than proactively creating programs to find these errors early¹⁾.

There are some important tools, processes and resources available to help prevent some Runtime Errors before the code is even executed.

• Static Code Analysis using Code Review Tools
• Have a Requirement Traceability plan
• Following the guidance provided in the Non-Functional Requirements section on Modifiability
• Understanding and using the Common Weakness Enumeration (CWE)
• Conducting Peer Reviews
• Establish a Case Management process with Automated Bug and Issue Tracking tools such as Jira (Bug tracking system) or Bugzilla
• Make sure there are clean compiles with no errors, warnings or informational messages
• Conducting in-depth, detailed testing covering requirement conformity checks outlined in 4.3.3.5 Testability, including:

  1. Unit Testing
  2. Integration Testing
  3. End-to-End Testing (E2E Testing)
  4. Smoke Testing
  5. Sanity Testing
  6. Regression Testing
  7. Acceptance Testing
  8. White Box Testing
  9. Black Box Testing
  10. Interface Testing
  11. Interoperability Testing

Return to Top

Runtime errors occur only after the Smart Contract Code has been compiled to a byte code, deployed to the blockchain and executed on the EVM. These runtime errors occur when Ethereum “thinks” that there is something wrong with the Smart Contract. If the Runtime error occurs during a Transaction, any State Changes made during the Transaction are canceled and the Transaction is reverted. Depending on the kind of error, all or some of the gas in the Transaction is consumed, or a portion is returned. Runtime errors are harder to troubleshoot than Syntax errors because the Solidity Compiler can not help with the diagnostics.

Runtime Errors are more serious than Syntax Errors since the contract has already been deployed to the blockchain, and it is not possible to just update the code by redeploying it.

Return to Top

Logic Errors occur when there is a fault in the logic expressed by the Software (SW) or when the (i.e., **''if''**-**''then''** statements) through the SW creates a situation which is wrong or incorrect. The chance of a Logic Error, increases with the number of Decision Points found with the SW code.

Logic Errors can originate anywhere in the System Lifecycle from its conception to its execution.

Sometimes Logic Errors are reported as a Bug, however, not all “Bugs” are discovered or reported. Logic errors resulting in a Crash are generally quite obvious and are generally reported. However, Bugs which do not result in a crash but can only be found with a detailed forensic analysis of the Datastores are some of the hardest to discover and even track down.

Sometimes a Logic Error is introduced when a developer misinterprets the requirements or inadvertently implements the boolean calculus used in the Control Flow operations. Some examples:

• Assuming that memory is nulled before it is used
• Incorrectly specifying the logical comparison operators (i.e., <, ⇐, ==, ===, '!=', >, or >=). For example, specifying a numerical check for a percent and specifying p >= 0 && p < 100 instead of p >= 0 && p ⇐ 100
• Incorrectly using the equivalent operators (i.e., ==, ===). == converts the variable values to the same type before performing comparison. This is called Type Coercion. === does not do any type conversion (coercion) and returns true only if both values and types are identical for the two variables being compared.
• Incorrectly using the assignment operator, =, instead of the comparison operator, ==
• Assuming that indexing arrays at one
• Incorrect incrementing a pointer instead of the value stored at the pointer
• Assuming a string is terminated by a null
• Comparing an empty string, “” to a null string

Sometimes, a Logic Error is a Bug because it introduces a Weakness making the System or Application Vulnerable for malicious Exploitation. These kinds of “Bugs” could exist for a long time (i.e., years) before they are actually exploited.

Software (SW), Firmware, and Hardware (H/W) weakness types that have security ramifications are also potential Logic Errors. These Weaknesses can be flaws, faults, Bugs, or other errors in Software, Firmware, or Hardware and could have been introduced during any phase of the System Lifecycle from conceptualization, requirements specifications, architecture, code, or implementation.

Currently, there are 900+ Weaknesses defined by the Common Weakness Enumeration (CWE) most of which can be found through Static Code Analysis and Testing