Chapter 4: Debug web application

Debugging web applications is an essential skill for software developers in Kenya’s dynamic tech sector, where delivering reliable, user-friendly systems is critical to organizational success. Identifying and correcting errors in source code ensures smooth operation of web platforms used by banks, county governments, universities, and retail businesses. This chapter focuses on practical methods to revise source code for errors, apply debugging tools, and implement error handling techniques that enhance software quality and maintainability.

4.1 Revise source code for errors

Revising source code means reading and running the code of a web application with the purpose of finding mistakes before users meet them. A mistake can stop a page from loading, make the application crash while it is being used, or let it run and give a wrong answer. A developer who can tell these cases apart knows where to look and which tools to use. Example: a developer building an online ordering page for a restaurant reads the code of the order total, runs it with known prices and checks that the screen shows the correct amount.

Revision is done line by line, first by reading the code and then by running it with test values whose correct result is already known. The next topics show the tools and methods for repairing what is found, so this topic concentrates on recognising the errors.

4.1.1 Types of Errors

Errors in source code fall into three main types according to when and how they show themselves: syntax errors, runtime errors and logical errors. Each type needs a different way of finding it, and the difference is summarised in the table below.

4.1.1.1 Logical

A logical error is a flaw in the reasoning of the code. The program has correct grammar and runs to the end without any message, but the result is wrong. Logical errors are often the hardest to find because nothing tells the developer that something is wrong. They are found by comparing the output with a result worked out by hand.

Example: a function meant to find the average of three marks in a JavaScript page forgets the brackets.

function average(a, b, c) {
  return a + b + c / 3;   // wrong: only c is divided by 3
}
console.log(average(60, 70, 80));   // 156.66666666666666, expected 70

Only the last number is divided by 3, because division is done before addition. The correct line puts the sum in brackets:

return (a + b + c) / 3;   // gives 70

Common causes of logical errors:

• Wrong formula or operator: Using a plus instead of a minus, or leaving out brackets, as in the example above.
• Off-by-one mistakes: A loop that runs once too often or once too few, because of <= instead of <.
• Wrong condition: An if test that uses the wrong comparison, so that the wrong branch of the code runs.
• Wrong variable: A variable meant for one purpose is used for another, for example a variable holding a user's role is used to store a product identifier.
• Misunderstood requirement: The code does exactly what the developer wrote but not what the client needed.

An off-by-one error in a loop over three items:

const items = ["Tea", "Sugar", "Milk"];
for (let i = 0; i <= items.length; i++) {   // wrong: should be i < items.length
  console.log(items[i]);
}

The output is Tea, Sugar, Milk and then undefined, because the loop also reads position 3, which does not exist. Changing <= to < removes the extra line.

To find logical errors, the developer tests with values whose answer is known, traces the code by hand with a pencil and paper, and writes automated tests that check the expected results.

4.1.1.2 Runtime

A runtime error, also called an exception, happens while the program is running, even though its syntax is correct. The program meets a situation it cannot handle, such as an operation that is impossible or data that is missing, and it stops or the feature fails. Runtime errors often depend on the data or the environment, so the same code may work for one user and fail for another.

Example 1: JavaScript reads a property of a value that does not exist.

const order = null;
console.log(order.total);

The browser console or Node.js shows TypeError: Cannot read properties of null (reading 'total'). The fix is to check the value before using it:

function total(order) {
  if (order === null) {
    return 0;
  }
  return order.total;
}
console.log(total(null));   // 0

Example 2: PHP receives a quantity of zero in a calculation that divides by it.

<?php
$items = 0;
echo 1500 % $items;

PHP 8 stops with a DivisionByZeroError with the message Modulo by zero. The same error with the division operator / or the function intdiv reports Division by zero. The code is correct grammar, but the value zero makes the operation impossible.

Common causes of runtime errors:

• Missing or empty values: Using a variable or an object that has not been given a value.
• Impossible operations: Division by zero, or converting text such as abc into a number.
• Missing files or resources: Opening a file that has been deleted or moved, or a database table that does not exist.
• Network and service failures: A call to a payment service or another system that does not respond.
• Wrong data types and sizes: Treating a number as text or an object as a list, or running out of memory with very large data. In some languages, such as Java, reading beyond the end of a list also stops the program.
• Unexpected user input: A form field left empty or filled with characters the code did not expect.

Runtime errors are reduced by checking inputs, handling exceptions with try and catch, and showing the user a clear message instead of a crash. The techniques for handling them are taught under error handling.

4.1.1.3 Syntax

A syntax error is a break in the grammar rules of a language, such as a missing bracket, quotation mark or semicolon, a misspelt keyword or an unclosed block. The language processor cannot understand the line, so the program, or the whole file, does not run. Syntax errors are the easiest to find because the browser, interpreter or compiler reports them and usually names the line.

Example 1: a missing closing bracket in JavaScript.

console.log("Welcome";

Node.js stops with SyntaxError: missing ) after argument list, and the browser console shows a similar message. Adding the missing bracket, console.log("Welcome");, corrects it.

Example 2: a missing semicolon in PHP.

<?php
$name = "Amina"
echo "Hello " . $name;

PHP reports PHP Parse error: syntax error, unexpected token "echo" and points to line 3. The error is reported at the next line, because PHP only notices the problem when it reaches the following statement, so the cause is often on the line above the one named in the message. The fix is a semicolon after "Amina".

Common causes of syntax errors:

• Unclosed brackets, quotes and braces: Each opening symbol needs its closing partner.
• Missing separators: A missing semicolon in PHP, or a missing comma between items of a list.
• Misspelt keywords: Writing fucntion for function, or ecoh for echo.
• Wrong use of case: JavaScript and PHP treat the variable names Total and total as different names.
• Wrong order of symbols: An else without a matching if.

In compiled languages such as Java or C#, the compiler also finds type mismatches and undeclared names before the program is built. These compilation errors are found in the same way as syntax errors, before the program can run. HTML and CSS behave differently: a browser does not stop on a mistake such as an unclosed tag or a misspelt property, but it may display the page wrongly or silently ignore the rule, so those mistakes are found by checking the page and with a validator.

Common sources of errors

Knowing where errors usually start helps a developer decide where to look first.

• Incomplete or incorrect requirements: A misunderstood or vague specification leads to code that works but does not do what the client needs.
• Poor code structure: Disorganised code, with the same logic copied into many places, makes it hard to follow the flow and easy to change one copy and forget the others.
• Inadequate testing: Features that are never run with unusual inputs keep their errors until real users find them.
• Lack of error handling: A call to a payment service that is not wrapped in error handling crashes the whole page when the network fails.
• External dependencies: A third-party library or service may change or fail, which breaks code that depended on it.

Chapter Summary

This chapter explored the essential process of debugging web applications, starting with the revision of source code to identify and classify errors into logical, runtime, and syntax types. Understanding these error categories is crucial for effective troubleshooting and maintaining application functionality. The chapter then examined the use of debugging tools and error handling techniques that support developers in isolating and resolving faults within the code. Source code revision was emphasized as a fundamental step in pinpointing issues before employing specialized debugging utilities. Additionally, the chapter highlighted the importance of systematic regression testing to verify that recent code changes do not introduce new errors or disrupt existing features. Together, these practices form a comprehensive approach to ensuring web applications operate reliably and meet user expectations.