DEV Community: Byte Corner

There Is No Such Thing as an Edge Case. Or is there?

Byte Corner — Fri, 02 Oct 2026 11:42:45 +0000

There Is No Such Thing as an Edge Case. Or is there?

"That's just an edge case."

You've probably heard it after someone finds a weird input, an unexpected state, or a combination of events nobody thought would happen.

Sometimes that's a perfectly reasonable description.

Sometimes it's how a bug gets dismissed.

The interesting question is not whether something is unusual.

It's whether your software needs to handle it.

🔴 The Problem

Imagine you're building a system that accepts a username.

You expect something like:

matej
alex
sarah

Then someone enters:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Is that an edge case?

Probably.

Now imagine someone enters:

admin

That's also a normal-looking username.

But if your system gives special privileges to admin because of an assumption hidden somewhere else, you've got a very different problem.

Neither input looks particularly strange.

The important difference is the assumption your system makes about it.

That's where "edge cases" get interesting.

🟢 The Solution

Instead of thinking:

"How likely is this to happen?"

try asking:

"What does the system need to do if this happens?"

Those are different questions.

A user entering 500 characters might be extremely rare.

But if the application accepts user input, someone eventually will.

A network request taking 10 seconds might be unusual.

But if your application depends on a network request, your code still needs a behavior for it.

A list containing zero items might seem like an edge case.

But if an empty list is a perfectly valid result, it's not really an edge case at all.

It's just another valid state.

const users = await getUsers();

if (users.length === 0) {
  showEmptyState();
}

The empty state isn't "special handling" if an empty result is part of the system's normal contract.

It's the contract.

⚡ The "Why"

The phrase "edge case" can make something sound like it belongs outside the main problem.

But software doesn't care how unusual a situation sounds.

It cares whether the situation is inside or outside the behavior you've decided to support.

Consider:

function divide(total, count) {
  return total / count;
}

Someone might say:

"What if count is zero? That's an edge case."

But if count can actually be zero, then the function has a decision to make.

Should it:

if (count === 0) {
  return 0;
}

throw?

if (count === 0) {
  throw new Error("count must be greater than zero");
}

or produce some other defined result?

The interesting part isn't which decision you make.

The interesting part is that not making a decision is also a decision.

The bug usually appears when the code has an assumption but nobody realized it was an assumption.

🧩 The Boundary Moves

Here's the uncomfortable part.

What counts as an edge case can change.

A system might originally have:

1–10 items

and treat 100 items as unusual.

Then the product grows.

Now customers regularly import 500 items.

The input didn't change.

The system's expectations did.

What used to be an edge case is now normal traffic.

That's why good software isn't built by trying to predict every bizarre thing that could ever happen.

It's built by making important assumptions explicit.

Instead of:

const firstUser = users[0];

renderUser(firstUser);

you might decide that an empty collection is valid:

if (users.length === 0) {
  renderEmptyState();
  return;
}

renderUser(users[0]);

Now the behavior is deliberate.

The code isn't merely hoping the assumption stays true.

🧠 The Takeaway

There isn't a universal list of edge cases.

An edge case is usually a situation that sits near the boundary of what your system expects to handle.

And those boundaries depend on the system.

So when someone says:

"That's just an edge case."

the useful follow-up isn't:

"How likely is it?"

Ask:

"Is this a state our software is supposed to handle?"

If the answer is yes, it isn't outside the problem.

It's part of the problem.

And if the answer is no, that's worth making explicit too.

Because an edge case isn't necessarily something rare.

Sometimes it's simply an assumption that hasn't been turned into a decision yet.

`async` Is Built on an Idea You Can See in `yield`

Byte Corner — Fri, 02 Oct 2026 11:42:35 +0000

async Is Built on an Idea You Can See in `yield`

yield and await aren't the same thing.

A generator isn't an async function, and an async function isn't a generator.

But there is an idea hiding underneath both of them that is easy to miss:

execution can stop here and continue later.

Once you see that, async/await starts looking a lot less magical.

🔴 The Problem

Consider a generator:

function* work() {
  console.log("A");

  yield;

  console.log("B");
}

Create it:

const task = work();

Nothing has run yet.

Now call next():

task.next();
// A

The generator runs until it reaches yield.

Then it stops.

It hasn't finished. It hasn't returned.

It's suspended.

Call next() again:

task.next();
// B

Execution continues exactly where it stopped.

That's unusual if you're used to ordinary functions.

Normally, you think of a function like this:

start → run → finish

A generator gives you:

start → run → suspend → resume → finish

And that middle part is the interesting bit.

If you want to see the whole thing together:

function* work() {
  console.log("A");

  yield;

  console.log("B");
}

const task = work();

task.next(); // A
task.next(); // B

The first next() runs until yield.

The second next() resumes the generator and continues after yield.

🟢 The Idea

yield makes suspension easy to see.

The generator essentially says:

"I'm stopping here. You can have control for a while. I'll continue later."

The caller decides when that happens:

const task = work();

task.next(); // runs until yield

// do something else

task.next(); // continue after yield

Nothing about this requires the generator to block JavaScript.

The generator's execution is paused while the rest of the program can continue.

That idea turns out to be extremely useful for asynchronous programming.

🔵 Promises Change Who Controls the Resume

Promises give us another way to express "continue later."

Without async/await, you might write:

doSomething().then((result) => {
  use(result);
});

The interesting part isn't really .then().

It's what the code is saying:

start something
       ↓
   not ready yet
       ↓
   continue later
       ↓
    use(result)

The function doing the work doesn't need to sit around waiting for the result.

Instead, the continuation is registered and runs when the Promise settles.

This is conceptually similar to what we saw with yield, even though the mechanisms are completely different.

With a generator, you explicitly resume the computation:

task.next();

With a Promise, settlement allows the continuation to be scheduled.

Different machinery.

Same useful idea:

this computation can suspend while something else happens.

🟣 Then `await` Makes It Look Normal

Now look at the same kind of operation using async/await:

async function work() {
  const result = await doSomething();

  use(result);
}

This looks almost like ordinary synchronous code.

That's intentional.

But the function isn't actually blocking at await.

When JavaScript reaches:

const result = await doSomething();

the async function suspends.

JavaScript gets control back.

When the Promise eventually fulfills, the async function continues:

use(result);

You can think of the execution like this:

work()
  ↓
run
  ↓
await Promise
  ↓
suspend
  ↓
JavaScript continues elsewhere
  ↓
Promise fulfills
  ↓
resume work()
  ↓
use(result)

The await marks a point where this particular piece of execution may need to give up control temporarily.

The rest of JavaScript doesn't have to wait with it.

⚡ The "Why"

Here's where yield becomes useful for understanding await.

With a generator, we can see the suspension point directly:

function* generator() {
  doSomething();

  yield;

  continueWork();
}

yield explicitly tells the generator:

"Stop here. I'll continue later."

await creates a similar boundary inside an async function:

async function asyncFunction() {
  const result = await doSomething();

  continueWork(result);
}

The interesting part isn't that await is asynchronous.

The interesting part is what happens to the function itself.

When execution reaches await, that invocation of asyncFunction cannot continue yet. Its continuation is put aside until the awaited Promise settles.

JavaScript is free to do other work in the meantime.

Then the async function resumes and continues with:

continueWork(result);

So you can put the two side by side:

generator

doSomething()
     ↓
   yield
     ↓
  suspend
     ↓
  next()
     ↓
continueWork()

async function

doSomething()
     ↓
  await
     ↓
  suspend
     ↓
Promise settles
     ↓
continueWork()

The mechanisms aren't the same.

A generator is explicitly resumed with next().

An async function resumes through the Promise machinery.

But both give us the same useful idea:

a computation can suspend at a specific point and continue later from that point.

That's the connection between yield and await.

🧩 The Important Difference

It's tempting to say "await is basically yield."

That's not quite right.

Generators are manually resumable:

const generator = work();

generator.next();
generator.next();

The caller controls when the generator moves forward.

An async function works differently.

When it reaches:

await promise;

the function's continuation is tied to the Promise.

And an async function always returns a Promise:

async function work() {
  return 42;
}

work().then((value) => {
  console.log(value);
});

So await isn't simply a nicer version of yield.

The mechanisms and semantics are different.

The shared idea is what matters.

🧠 The Mental Model

If you remember only one thing, make it this:

yield
  ↓
"Pause this computation.
 Resume me when the caller decides."

await
  ↓
"Pause this computation.
 Resume me when this Promise is ready."

Both let a computation give control back instead of insisting on finishing immediately.

yield makes that behavior visible.

await hides it behind syntax that looks sequential.

That's part of why async/await feels so natural.

It lets you write:

const user = await getUser();
const posts = await getPosts(user.id);

render(user, posts);

as though the function simply runs from top to bottom.

But underneath that simple-looking code are suspension points.

The function can stop.

The rest of JavaScript can keep moving.

Then the function can pick up where it left off.

And once you've seen that idea in yield, await doesn't look quite so magical anymore.

Different mechanisms.

Same surprisingly useful idea:

a computation can suspend now and continue later.

Get item index and item count in CSS

Byte Corner — Fri, 02 Oct 2026 11:42:23 +0000

sibling-index() and sibling-count()

For years, CSS had no way of knowing which position an element had among its siblings, or how many siblings there were. Now it does. With sibling-index() and sibling-count() you can finally get the item index and item count directly in CSS.

sibling-index() returns the element's position among its siblings, starting at 1.
sibling-count() returns the total number of siblings, including the element itself.

How we used to do it

Before these functions existed, the only option was to number everything by hand. You had to put the total count on the parent and an index on every child, using inline custom properties.

HTML

<div class="parent" style="--n: 4;">
  <div class="child" style="--i: 1;"></div>
  <div class="child" style="--i: 2;"></div>
  <div class="child" style="--i: 3;"></div>
  <div class="child" style="--i: 4;"></div>
</div>

CSS

.parent {
  display: flex;
  gap: 1em;
  max-inline-size: 40rem;
  margin-inline: auto;
  .child {
    aspect-ratio: 1;
    flex: 1;
    background: hsl(calc(360 / var(--n) * var(--i)) 100% 50%);
  }
}

This works, but it is tedious. Every item needs its own --i, and the moment you add or remove an item, you have to update --n and renumber the rest.

The new way

With sibling-index() and sibling-count(), all of that manual work disappears. The HTML is just plain markup, and the CSS figures out the rest on its own.

Here is the same example again: a unique background color for every item, based on its index.

HTML

<div class="parent">
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
</div>

CSS

.parent {
  display: flex;
  gap: 1em;
  max-inline-size: 40rem;
  margin-inline: auto;
  .child {
    aspect-ratio: 1;
    flex: 1;
    background: hsl(calc(360 / sibling-count() * sibling-index()) 100% 50%);
  }
}

The hue is 360 / count * index, so the colors are spread evenly around the color wheel. Add a fifth child and every hue adjusts automatically.

Using them as custom properties

You can also store the functions in custom properties, which keeps your code shorter if you use them in many places.

CSS

:root {
  --n: sibling-count();
  --i: sibling-index();
}

.parent {
  display: flex;
  gap: 1em;
  max-inline-size: 40rem;
  margin-inline: auto;
  .child {
    aspect-ratio: 1;
    flex: 1;
    background: hsl(calc(360 / var(--n) * var(--i)) 100% 50%);
  }
}

Where are they counted?

You might expect --n and --i to be calculated on :root, since that is where they are defined. They are not. sibling-index() and sibling-count() count the items where the variable is used, not where it is defined.

In this example the variables are defined on :root, but they are used on .child. So they count each .child item, not the root.

This is what makes it possible to define them once on :root and reuse them everywhere.

See it in action

The first example keeps things simple: each item gets a color based on its position in the group. Add or remove .child elements and both sibling-index() and sibling-count() update automatically.

In another example, the same idea can drive much more than colors. Here, the sibling position determines each box's angle, distance from the center, rotation, color, and animation delay.

Change the number of .box elements and the entire 3D arrangement adapts to it.

Why `finally` Runs Before `return` Takes Effect

Byte Corner — Fri, 02 Oct 2026 11:42:04 +0000

Why Your `finally` Runs After `return`

A return looks like the end of a function.

But put a finally after it:

function getValue() {
  try {
    return 42;
  } finally {
    console.log("cleanup");
  }
}

console.log(getValue());

The output is:

cleanup
42

The return happened.

The function just hadn't finished leaving yet.

🔴 The Problem

It's tempting to think of return as:

return
  ↓
function stops immediately

But with finally, there's another step.

When JavaScript reaches:

return 42;

it evaluates 42 and prepares to return it.

Before the function actually completes, JavaScript runs the finally
block.

So the flow is roughly:

return 42
    ↓
remember 42
    ↓
run finally
    ↓
finish returning 42

The important part is that the return value has already been determined.

finally just gets to run before the function actually exits.

🟢 The Solution

This is exactly what makes finally useful for cleanup.

Imagine something that needs to be closed regardless of what happens:

function readFile(file) {
  try {
    return file.read();
  } finally {
    file.close();
  }
}

file.read() can still determine the value returned to the caller.

But file.close() runs before the function actually leaves.

Without finally, you'd have to duplicate the cleanup:

function readFile(file) {
  try {
    const result = file.read();

    file.close();

    return result;
  } catch (error) {
    file.close();

    throw error;
  }
}

With finally, the cleanup has one place:

function readFile(file) {
  try {
    return file.read();
  } finally {
    file.close();
  }

Whether try returns, throws, or finishes normally, finally gets its
chance to run.

⚡ The Dangerous Part

finally isn't limited to cleanup.

It can actually change how the function finishes.

function getValue() {
  try {
    return 42;
  } finally {
    return 100;
  }
}

console.log(getValue());

The result is:

The original return 42 prepared the function to return 42.

Then finally executed another return.

That new return becomes the function's actual result.

The same thing can suppress an error:

function getValue() {
  try {
    throw new Error("Boom");
  } finally {
    return 42;
  }
}

console.log(getValue());

Instead of throwing, the function returns:

The return inside finally replaced the pending exception.

That's why returning from finally is usually a bad idea.

You're no longer just cleaning up.

You're changing the outcome.

🧠 The Takeaway

Don't think of:

return value;

as:

"I am completely done now."

Think of it as:

"I know how I want to finish."
        ↓
     finally
        ↓
"I actually leave now."

So this is perfectly reasonable:

try {
  return result;
} finally {
  cleanup();
}

But this deserves suspicion:

try {
  return result;
} finally {
  return somethingElse;
}

return decides the result.\
finally gets the last chance to change how the function exits.

DEV Community: Byte Corner

There Is No Such Thing as an Edge Case. Or is there?

There Is No Such Thing as an Edge Case. Or is there?

🔴 The Problem

🟢 The Solution

⚡ The "Why"

🧩 The Boundary Moves

🧠 The Takeaway

`async` Is Built on an Idea You Can See in `yield`

async Is Built on an Idea You Can See in yield

🔴 The Problem

🟢 The Idea

🔵 Promises Change Who Controls the Resume

🟣 Then await Makes It Look Normal

⚡ The "Why"

🧩 The Important Difference

🧠 The Mental Model

Get item index and item count in CSS

sibling-index() and sibling-count()

How we used to do it

The new way

Using them as custom properties

Where are they counted?

See it in action

Why `finally` Runs Before `return` Takes Effect

Why Your finally Runs After return

🔴 The Problem

🟢 The Solution

⚡ The Dangerous Part

🧠 The Takeaway

async Is Built on an Idea You Can See in `yield`

🟣 Then `await` Makes It Look Normal

Why Your `finally` Runs After `return`