Error handling σε custom εφαρμογές: πώς να βοηθάτε τον χρήστη χωρίς να αποκαλύπτετε τεχνικά μυστικά

Κάθε web application κάποια στιγμή θα εμφανίσει λάθος. Ένα API μπορεί να αποτύχει, η βάση να καθυστερήσει, ένα αρχείο να μην ανέβει, μια πληρωμή να μη γυρίσει απάντηση ή ένας χρήστης να συμπληρώσει μη έγκυρα δεδομένα.

Το ζητούμενο δεν είναι να μη συμβαίνουν ποτέ λάθη. Το ζητούμενο είναι να αντιμετωπίζονται με τρόπο χρήσιμο για τον χρήστη και ασφαλή για την επιχείρηση.

Το λάθος μήνυμα μπορεί να γίνει διαρροή

Το OWASP επισημαίνει ότι detailed errors, stack traces, database dumps και εσωτερικοί κωδικοί δεν πρέπει να εμφανίζονται στον χρήστη. Αυτές οι πληροφορίες μπορεί να βοηθήσουν έναν επιτιθέμενο να καταλάβει framework, database, paths ή εσωτερική λογική.

Κακό παράδειγμα:

• SQLSTATE[23000]: Integrity constraint violation at /var/app/services/UserService.php line 184

Καλύτερο μήνυμα προς χρήστη:

• «Δεν μπορέσαμε να ολοκληρώσουμε την ενέργεια. Δοκιμάστε ξανά ή επικοινωνήστε με την ομάδα υποστήριξης.»

Η τεχνική λεπτομέρεια πρέπει να πάει στα logs, όχι στο UI.

Διαφορετικά λάθη, διαφορετική αντιμετώπιση

Δεν είναι όλα τα errors ίδια.

Υπάρχουν:

• validation errors
• authorization errors
• not found errors
• payment failures
• third-party API failures
• rate limits
• unexpected server errors

Τα validation errors πρέπει να είναι συγκεκριμένα και δίπλα στο σωστό πεδίο. Τα authorization errors πρέπει να μην αποκαλύπτουν περισσότερη πληροφορία από όσο χρειάζεται. Τα unexpected errors πρέπει να είναι γενικά στο UI αλλά πλήρη στα internal logs.

Validation errors που βοηθούν

Σε φόρμες, ο χρήστης πρέπει να ξέρει τι να διορθώσει.

Παραδείγματα χρήσιμων μηνυμάτων:

• «Συμπληρώστε email σε σωστή μορφή.»
• «Το αρχείο πρέπει να είναι PDF έως 10MB.»
• «Η ημερομηνία κράτησης δεν είναι διαθέσιμη.»

Παράδειγμα κακού μηνύματος:

• «Invalid input.»

Το ασφαλές error handling δεν σημαίνει ασαφές UX. Σημαίνει ότι δίνουμε χρήσιμη πληροφορία χωρίς εσωτερικές λεπτομέρειες.

Logs και correlation IDs

Όταν κάτι πάει στραβά, η ομάδα πρέπει να μπορεί να το βρει. Για αυτό χρειάζονται logs με correlation IDs.

Πρακτικά, ένα error μπορεί να εμφανίζει στον χρήστη:

• «Κωδικός αναφοράς: REQ-8F32»

Και στα logs να υπάρχουν:

• timestamp
• request id
• user id όπου επιτρέπεται
• endpoint
• error category
• stack trace σε ασφαλές internal περιβάλλον
• σχετικό external service

Έτσι η υποστήριξη μπορεί να διερευνήσει χωρίς να εκτίθενται τεχνικά στοιχεία στον πελάτη.

APIs και status codes

Σε APIs, τα status codes πρέπει να είναι συνεπή.

Παραδείγματα:

• 400 για λάθος input
• 401 όταν λείπει authentication
• 403 όταν ο χρήστης δεν έχει δικαίωμα
• 404 όταν δεν υπάρχει resource ή δεν πρέπει να αποκαλυφθεί
• 409 για conflict
• 429 για rate limit
• 500 για απρόβλεπτο server error

Το response body πρέπει να είναι χρήσιμο αλλά όχι αποκαλυπτικό. Μην επιστρέφετε stack traces, SQL queries ή internal service names στον client.

Πώς το κάνει η Ai Foundry

Στην Ai Foundry σχεδιάζουμε error handling ως μέρος της αρχιτεκτονικής εφαρμογής. Για portals, CRM, booking systems, e-shop flows και AI automations, ορίζουμε ποια λάθη πρέπει να βλέπει ο χρήστης, τι καταγράφεται στα logs, πώς γίνεται debugging και πώς αποφεύγονται διαρροές.

Αυτό βοηθά την εφαρμογή να είναι πιο αξιόπιστη στην καθημερινή χρήση. Ο χρήστης παίρνει καθαρή οδηγία, η ομάδα έχει στοιχεία για διόρθωση και η επιχείρηση δεν αποκαλύπτει εσωτερικές λεπτομέρειες.

Checklist

Ελέγξτε:

• αν τα production errors δεν εμφανίζουν stack traces
• αν validation messages είναι χρήσιμα
• αν authorization errors δεν αποκαλύπτουν άσκοπα resources
• αν υπάρχουν correlation IDs
• αν logs περιέχουν αρκετή πληροφορία για debugging
• αν logs δεν περιέχουν passwords, tokens ή ευαίσθητα δεδομένα
• αν API status codes είναι συνεπή
• αν error paths έχουν δοκιμαστεί και όχι μόνο το happy path

Το καλό error handling φαίνεται όταν κάτι αποτύχει. Τότε κρίνεται αν η εφαρμογή είναι πραγματικά επαγγελματική.