DEV Community

Cover image for 🧨 The Bugs That Almost Broke Sortify (And How I Crushed Them)
Rolan Lobo
Rolan Lobo

Posted on

🧨 The Bugs That Almost Broke Sortify (And How I Crushed Them)

#programming #productivity #beginners #discuss

Let me tell you something.

Apps don’t usually break because of complex algorithms.

They break because of:

  • A 0-byte file.
  • A random binary blob pretending to be text.
  • A filename like report:final*version?.docx
  • Or an undo operation that travels back in time… badly.

Sortify ran into all of these.
So I did what every developer eventually has to do:

I went into defensive programming mode.

This is the story of how I hardened Sortify’s invalid input handling — and made it way more stable in the process.

Check it out on GitHub:
🔗 Sortify — automatic file organizer

🗂️ 1. The “Empty File” Problem

You’d think an empty file wouldn’t be dangerous.

It’s literally nothing.

But that’s the problem.

No content → extraction logic behaves weirdly → AI categorization becomes unreliable.

So now we explicitly detect 0-byte files before doing anything:

if file_size_bytes == 0:
    logging.warning(f"Empty file detected (0 bytes): {file_path}")
Enter fullscreen mode Exit fullscreen mode

What happens now?

  • ✅ Empty files are detected instantly
  • ✅ Logged properly
  • ✅ Categorized using filename only
  • ✅ No crashes
  • ✅ No silent weirdness

Instead of “why did this behave strangely?”
Now it’s “Ah, it’s empty. Makes sense.”

Predictable > Magical.

💣 2. Binary Files Pretending to Be Text

This one was sneaky.

Some files looked harmless.

But internally?

Binary junk.

And when text extraction libraries try to read binary data…

You get:

  • Exceptions
  • Garbage output
  • Or mysterious failures

So I built a binary detector.

🧠 How It Works

We check:

  • First 8KB of the file
  • Presence of null bytes (\x00)
  • Ratio of non-printable characters

If more than 30% of characters are non-printable, we treat it as binary.

Why 30%?

Because real text files don’t look like corrupted alien transmissions.

If file is binary: 

logging.info("Binary file detected, skipping content extraction")
Enter fullscreen mode Exit fullscreen mode

And we:

  • ✅ Skip text extraction
  • ✅ Fall back to filename-based categorization
  • ✅ Log everything
  • ✅ Avoid crashes completely

Even if the file extension lies.

Doesn’t matter if it’s .txt, .md, or .conf.

Binary is binary.

No more surprise explosions.

😩 3. Windows Filename Rage

Previously, if someone tried to rename a file using invalid Windows characters…

They got a boring, unhelpful error.

Now?

We explain exactly what Windows hates:

Windows does not allow these characters in filenames:
  \ (backslash)  / (forward slash)  : (colon)
  * (asterisk)   ? (question mark)  " (quote)
  < (less than)  > (greater than)  | (pipe)
Enter fullscreen mode Exit fullscreen mode

Plus a clear:

Please remove these characters and try again.

Simple change.

Massive UX improvement.

No more guessing what went wrong.

🕰️ 4. The Undo Operation That Could Have Been Dangerous

Undo is supposed to feel magical.

But under the hood, it’s risky.

What if:

  • The moved file was deleted?
  • The original location now has a new file?
  • Something changed between operations?

Previously, this could cause crashes or accidental overwrites.

Now?

We check everything.

Before undoing:

  • ✅ Does the moved file still exist?
  • ✅ Is the original location free?

If not?

We stop and clearly explain why:

Cannot undo: Original location is already occupied.
A file already exists at: ...
Please manually verify and move the file if needed.
Enter fullscreen mode Exit fullscreen mode

No corruption.
No overwriting.
No chaos.

This one was a critical-level fix.

📊 Before vs After

Before

  • Empty files behaved weirdly
  • Binary files could crash extraction
  • Error messages were vague
  • Undo could break in edge cases

After

  • Empty files detected and logged
  • Binary files safely skipped
  • Clear, human-readable error messages
  • Undo operations protected and safe

It feels like the app matured overnight.

💡 What This Really Is

This wasn’t a “new feature” release.

This was a stability hardening phase.

The kind of work users never see.

But they feel it.

Because the app stops:

  • Crashing randomly
  • Acting unpredictably
  • Failing silently

Instead, it behaves like a professional desktop application.

🚀 Final Thought

The difference between a prototype and a production-ready app?

Not fancy AI.
Not cool UI.

It’s this:

Handling weird, messy, real-world input gracefully.

Users will always find edge cases.

Your job is to make sure they don’t break everything when they do.

Sortify is now much harder to break.

And honestly?

That feels better than shipping a new feature. 💙

Top comments (0)