Great question—you’re right to dig into the tangible downsides beyond just extra lines of code. Let’s break down the key issues you’ll run into if you wrap a purely synchronous function like your add() method in a Promise:

1. Unnecessary Event Loop Overhead & Timing Shifts #

JavaScript’s event loop processes synchronous code first, then clears the microtask queue (where Promise callbacks live). When you wrap a synchronous operation in a Promise, even though the work finishes immediately, the resolution gets pushed to the microtask queue.

For your recursive addNode() example, this means every call to add() will now introduce a tiny delay before the Promise chain proceeds. While a single instance is negligible, high-frequency calls (like deep recursion) will accumulate overhead—wasting CPU cycles on microtask scheduling instead of actual work. Worse, this can break timing-dependent logic: if any code expects the add() operation’s side effects (like the updated list length) to be available immediately, it’ll fail because those changes won’t propagate until the next microtask tick.

2. More Complex Error Handling #

Synchronous errors in add() (like your IllegalArgumentError) are straightforward to catch with try/catch. But wrap it in a Promise, and those errors become Promise rejections instead. This forces you to:

• Use .catch() handlers in your Promise chain, or wrap calls in try/catch if using async/await
• Handle a split error model (some errors throw synchronously, others reject asynchronously) if other parts of your code still use the synchronous version
• Adjust your recursive logic to properly terminate on rejection (since a thrown error stops execution immediately, but a rejected Promise needs explicit handling to halt recursion)

This adds unnecessary mental overhead and increases the chance of unhandled rejection bugs.

3. Misleading Code Semantics #

A Promise return type signals to other developers that a function performs asynchronous work (like I/O, timers, or network calls). Wrapping a synchronous function in a Promise lies about what the function actually does—other engineers might waste time looking for hidden async logic, or assume they can safely run non-blocking operations alongside it when they can’t.

In your case, add() is just a validated Array.push()—making it return a Promise muddles its core purpose and makes your codebase harder to reason about.

4. Worse Debuggability #

Synchronous errors produce clean, direct call stacks that point straight to the line where the error occurred. When you wrap synchronous code in a Promise, errors get caught and re-emitted as Promise rejections, which can truncate or obscure the call stack.

For example, if your add() throws an error, a synchronous call will show a stack trace starting at the throw line in add(). But with a Promise-wrapped version, the stack trace might start at the Promise’s internal resolution logic, forcing you to trace back through the Promise chain to find the actual source of the error.

A Better Middle Ground for Your Use Case #

Since your addNode() needs to be async (for recursive Promise chaining), you don’t need to make add() itself return a Promise. Just keep add() synchronous, and resolve the Promise in addNode() with its result—like you’re already doing! That way you keep the simplicity of synchronous code where it makes sense, while maintaining the async contract for the functions that need it.

内容的提问来源于stack exchange，提问作者Vegaaaa