The Law of Loudness: Why Your Code Should Scream, Not Whisper

Source: Dev.to

We have all been there. It is 4 PM on a Friday. You are staring at a stack trace that makes no sense.
The error is the classic JavaScript killer: Cannot read properties of null (reading ‘email’).
You click the line number. It points to a React component trying to render a user profile. The code looks fine—the user object should be there. Why is it null?

Tracing the data back, you discover a helper function that calls a service, which calls an API utility. Five layers deep, the culprit is a function named getUser. It encountered a database error, but instead of telling anyone, it quietly returned null and let the application keep running.

This is called “Passing the Buck.” The symptom (the crash) appears minutes and many files away from the cause (the database failure), making it the hardest type of bug to debug.

The Silent Failure

Junior engineers often fear crashing the application and therefore catch errors, sweep them under the rug, and return a “safe” value such as null, false, or -1. This puts the application into Zombie Mode—it keeps running half‑dead.

When you return null silently, you are outsourcing error handling to the caller. Every place that uses your function must remember to check for null. If even one developer forgets, the app crashes later and nobody knows why.

Senior engineers follow a different rule: If a function cannot do what its name promises, it should throw an error immediately. This is The Law of Loudness.

If I call a function named getUser(id), I expect a user. I do not expect null. If you can’t give me a user because the database is on fire, don’t hand me an empty box and smile. Scream at me.

We want to Fail Fast. Use exceptions to protect data integrity; if the data is bad, stop the factory line immediately.

Before vs. After: Applying the Law of Loudness

BEFORE – The “Safe” Silent Failure

// BEFORE: The "Safe" Silent Failure
function getUser(id) {
  // If the DB is down, we hide it.
  if (!db.isConnected()) {
    console.log("DB is down...");
    return null; // <--- Passing the buck
  }

  const user = db.find(id);

  // If user isn't found, we return null again.
  // Is it null because they don't exist?
  // Or because the DB is broken?
  // The caller will never know.
  return user || null;
}

// THE RESULT:
// The caller code assumes it got a user.
const user = getUser(50);
// CRASH happens here, 10 lines later.
console.log(user.profile.email);

AFTER – The Law of Loudness

// AFTER: The Law of Loudness
function getUser(id) {
  // 1. Guard Clause for System Failure
  if (!db.isConnected()) {
    // Stop execution immediately. We know EXACTLY what broke.
    throw new DatabaseConnectionError('Cannot fetch user: DB is down');
  }

  const user = db.find(id);

  // 2. Guard Clause for Data Integrity
  if (!user) {
    // Differentiate between "System Broken" and "Not Found"
    throw new NotFoundError(`User with ID ${id} does not exist`);
  }

  return user;
}

// THE RESULT:
// The crash happens INSIDE getUser.
// The stack trace points exactly to the line that failed.
// We know if it was a DB error or a missing user instantly.

Benefits of Being Loud

• Debugging Speed – When the app crashes, the stack trace points directly to getUser. You know immediately whether the DB is down or the user is missing, saving hours of hunting null values through UI components.
• Trust – Callers don’t need repetitive if (user !== null) checks. If execution proceeds past the call, you have a valid user.
• Data Integrity – Prevent “Zombies”—half‑formed data objects—from floating around your state management and causing weird bugs (e.g., saving a profile with an undefined ID).

Don’t be afraid of the red text in the console. Red text is honest. A silent null is a lie; it tells the system everything is fine when the house is actually burning down.

The Rule

1. Expected errors (e.g., searching for a product that might not exist) – return a specialized Result type or null only if null is a valid domain state.
2. Unexpected errors (network down, bad configuration, missing required data) – throw. Loudly.

Conclusion

Stop writing code just to please the compiler. Embrace the Law of Loudness, fail fast, and let errors be heard.

This article is an excerpt from my handbook, “The Professional Junior: Writing Code that Matters.” It’s a tactical field guide to unwritten engineering rules.

👉 Get the Full Handbook Here