Accéder au contenu principal
Why Apps Crash (And How Developers Prevent It)

✨ Why Apps Crash (And How Smart Developers Keep Them Running)

😠 The classic: “Something went wrong…”

You tap a button in your favorite app. You wait. Suddenly... nothing. Or worse, the app freezes, and you get that lovely error message: “Oops! Something went wrong.”

Why does this happen? And more importantly—how can developers prevent it?

🌍 Apps talk to other computers (a lot)

Most modern apps don’t work alone. They constantly request data from servers. This is called an API request.

Imagine an app asking for:

  • Temperature
  • Wind speed
  • Air quality

If just one server is down, everything fails. You get nothing.

🔥 The old way: All or nothing

Promise.all([
  fetch('/temperature'),
  fetch('/wind'),
  fetch('/airquality')
])
.then(handleResults)
.catch(showErrorToUser);

If any one of these fetches fails, the entire thing fails. The user sees an error, even if some data was available.

✅ The smarter way: Take what works

Promise.allSettled([
  fetch('/temperature'),
  fetch('/wind'),
  fetch('/airquality')
])
.then(results => {
  results.forEach(result => {
    if (result.status === 'fulfilled') {
      console.log('✅ Success:', result.value);
    } else {
      console.warn('❌ Failed:', result.reason);
    }
  });
});

This lets your app continue to show what did work, instead of crashing entirely.

🧪 Real-world example: Trip planner app

Your travel app loads:

  • 🚆 Next train to Brussels
  • ✈️ Cheapest flight to Paris
  • 🚕 Local taxis near you

Flight API down?
Old logic: Total crash.
New logic: Train + taxi still load. You keep going.

👨‍💻 Why it matters

APIs fail. Networks glitch. Servers hiccup. But your app shouldn’t collapse because of it.

Promise.allSettled() helps you:

  • Keep the app responsive
  • Show partial results
  • Avoid frustrating the user

✅ TL;DR

The Problem The Fix
One API fails → All fail One API fails → Others still work
User sees nothing User sees what’s available

Want more dev insights without the fluff? Stick around—next up: Why some apps are painfully slow, and how developers speed them up.

Commentaires

Posts les plus consultés de ce blog

🔓 Peut-on vraiment "craquer" un mot de passe ? Une démonstration pas à pas 👇 Ce qu’on va faire Dans cet article, on montre concrètement comment un outil gratuit (présent dans Kali Linux) peut retrouver un mot de passe simple en quelques secondes. Mais on va aussi voir pourquoi un mot de passe complexe bloque toute attaque — et comprendre pourquoi. 🛠️ Les outils nécessaires On utilise un outil connu des experts cybersécurité : John the Ripper (inclus dans Kali Linux, utilisé pour les tests d’audit de mots de passe). John ne "pirate" pas un système en ligne. Il teste des mots de passe chiffrés en local , comme s’il avait volé un fichier de mots de passe (un hash). Cela simule ce qui se passe quand un hacker récupère une base de données de mots de passe cryptés . ✅ Étape 1 – Créer un mot de passe simple et le chiffrer On va créer un mot de passe : bonjour123 Puis on le chiffre avec cette commande : echo -n "bonjour123" | openssl passwd -...
Comprendre les Buffer Overflows - Analyse Technique 🗂️ Table des matières 🧠 Introduction 📚 Comprendre la vulnérabilité 🛠️ Compilation sans protections 🔎 Mécanisme d'exploitation 🛡️ Protections modernes 🧰 Outils à connaître 🔧 Environnement Docker 📌 Rappel sur les registres : Lorsqu'une fonction est exécutée, plusieurs registres processeur sont utilisés. Parmi eux : RIP (x86_64) : registre d'instruction, contient l'adresse de la prochaine instruction à exécuter. EIP (x86 32-bit) : équivalent de RIP sur les systèmes 32 bits. RBP / EBP : pointeur de base de la pile, souvent utilisé pour référencer les variables locales et les arguments. RSP / ESP : pointeur de sommet de la pile, toujours à jour avec l'adresse actuelle du haut de pile. Ces registres sont au cœur des méca...
Détection d'une attaque DDoS avec Snort et Kali Linux Mener une Attaque DDoS avec Kali Linux et la Détecter avec Snort Avertissement : ce tutoriel est destiné à un usage éthique et pédagogique dans un environnement de test. Toute utilisation non autorisée est interdite. 1. Objectif Simuler une attaque DDoS depuis Kali Linux et observer sa détection en temps réel par Snort. Cette approche est parfaite pour un exercice red/blue team. 2. Préparation de l'environnement Attaquant : Kali Linux Cible : Ubuntu Server avec Apache Snort IDS : sur une machine intermédiaire (interface en mode promiscuous) 3. Simulation d'une attaque DDoS 3.1 SYN Flood avec hping3 Le SYN flood sature les connexions TCP en enchaînant des paquets SYN sans finaliser le handshake. sudo hping3 -c 50000 -d 120 -S -w 64 -p 80 --flood --rand-source 192.168.1.20 3.2 HTTP Flood avec GoldenEye GoldenEye provoque un déluge de requêtes HTT...