Περί χειρισμών εξαιρέσεων

[Lanike71]

Νομίζω ότι ένα μεγάλο κεφάλαιο είναι ο χειρισμός εξαιρέσεων στον προγραμματισμό. Αυτό που θέλω να ρωτήσω είναι το εξής:

Ποιά είναι η σωστή πρακτική για το χειρισμό εξαιρέσεων σε ένα πρόγραμμα; Το να αφήσεις να συμβεί η εξαίρεση και να ενημερώσεις με μήνυμα ή να μην το αφήσεις να συμβεί ποτέ; Βέβαια η δεύτερη περίπτωση απαιτεί σίγουρα περισσότερο κώδικα, αλλά στα μάτια μου είναι πιο σωστό (ως χρήστης πάντα).

Παράδειγμα : Περιμένω σε ένα πεδίο να εισαχθεί ένας αριθμός από 1-10. Δύο λύσεις : Επιτρέπω να πληκτρολογηθεί οτιδήποτε και ενημερώνω με μήνυμα για λάθος ή αντί για πεδίο, εισάγω λίστα με αριθμούς 1-10 και δεν έχω να ανησυχώ για το τι θα πληκτρολογηθεί.

[k33theod]

Προσωπική μου γνώμη είναι ότι με το 2ο τρόπο είναι πιο σταθερό το πρόγραμμα. Ωστόσο καλό είναι να χειρίζεσαι το λάθος και με error handling. Παράδειγμα έχω μια κλίμακα με βαθμολογία μαθητών 1-10 που μπαίνει με λίστα όπως λες. Αν κάποιος βρεί ένα τρόπο να το παρακάμψει και βάλει ένα αριθμό 12 πρέπει να το πιάσεις κάπως. Ή έβαλες στη λίστα κατα λάθος αντί για 2 20. Οπότε και στις 2 περιπτώσεις πρέπει να κάνεις raise error (python)

 

[the other one]

Αν μπορείς να enforce το σωστό χειρισμό κάνε το. Καλό είναι αυτό που θα φτιάξεις να είναι όσο πιο stupid proof γίνεται. Κι αυτό δεν αφορά μόνο το χρήστη αλλά και εσένα το developer (defensive programming, strict typing κλπ).

 

Επειδή μιλάς για εξαιρέσεις αν και άλλο πράγμα ρωτάς εδώ, καλό είναι κατά τη γνώμη μου να κάνεις catch ό,τι μπορείς εσωτερικά και να μη θεωρείς πως "οκ αν σκάσει έσκασε".

[defacer]

Όταν έχεις την επιλογή "να μη το άφησεις να συμβεί" τότε δε μιλάμε για χειρισμό σφαλμάτων. Τα σφάλματα εξ ορισμού δε μπορείς να μη τα αφήσεις να συμβούν. Οπότε θα έλεγα η ερώτηση όπως διατυπώθηκε είναι λίγο red herring.

Για το σενάριο που συζητάμε, εφόσον μας ενδιαφέρει να κάνουμε input validation, αυτό θα πρέπει να γίνει με ένα τρόπο που δεν τίθεται καν θέμα να συμβεί σφάλμα. Έχω κώδικα validation, ο λόγος της ύπαρξής του είναι να μας πει αν όλα καλά με την είσοδο. Δεν τίθεται θέμα σφάλματος "είπα μέχρι 10 και έβαλες 20" γιατί όσον αφορά τον validation code, το 20 δεν είναι σφάλμα. Είναι απλά μια τιμή που χειριζόμαστε με τάδε τρόπο.

Το αν θα το κάνεις αυτό και πώς εξαρτάται από το κοινό του προγράμματος και τον αναμενόμενο χρόνο ζωής του.

5 minutes ago, the other one said:

καλό είναι κατά τη γνώμη μου να κάνεις catch ό,τι μπορείς εσωτερικά και να μη θεωρείς πως "οκ αν σκάσει έσκασε"

Και μέσα στο catch τι θα κάνεις;

 

Edit: όπως είπα κατά την άποψή μου εδώ δεν τίθεται καν θέμα exception αλλά επειδή ήδη συζητιέται, έχω μια απάντηση στο stack overflow εδώ. Η ερώτηση ήταν για PHP, η απάντηση είναι γενική.

Επεξ/σία 7 Ιουλίου 2018 από defacer

[the other one]

Αναφορά σε κείμενο

You should not be catching the exception unless you intend to do something meaningful.

 

Αυτό θα μπορούσε να ειπωθεί αντίστροφα αναλόγως με το τι θα θεωρούσε κάποιος "meaningful". Πχ το "display an error message and rethrow" δεδομένου πως όταν μιλάμε για exception handling συνήθως έχουμε στο νου μας exceptions τα οποία εμείς excplicitly κάνουμε throw στον κώδικα και πολλές φορές έχουμε κάνει wrap πολύ όμορφα σε δικές μας κλάσεις τις οποίες συνήθως έχουμε κάθε λόγο να διαβάσουμε στο runtime, εκεί το να πετάξεις ένα message και να τη πετάξεις πίσω είναι νομίζω το πιο απλό που μπορείς να κάνεις.

[karaLRS]

41 λεπτά πριν, defacer είπε

Όταν έχεις την επιλογή "να μη το άφησεις να συμβεί" τότε δε μιλάμε για χειρισμό σφαλμάτων. Τα σφάλματα εξ ορισμού δε μπορείς να μη τα αφήσεις να συμβούν. Οπότε θα έλεγα η ερώτηση όπως διατυπώθηκε είναι λίγο red herring.

Για το σενάριο που συζητάμε, εφόσον μας ενδιαφέρει να κάνουμε input validation, αυτό θα πρέπει να γίνει με ένα τρόπο που δεν τίθεται καν θέμα να συμβεί σφάλμα. Έχω κώδικα validation, ο λόγος της ύπαρξής του είναι να μας πει αν όλα καλά με την είσοδο. Δεν τίθεται θέμα σφάλματος "είπα μέχρι 10 και έβαλες 20" γιατί όσον αφορά τον validation code, το 20 δεν είναι σφάλμα. Είναι απλά μια τιμή που χειριζόμαστε με τάδε τρόπο.

Το αν θα το κάνεις αυτό και πώς εξαρτάται από το κοινό του προγράμματος και τον αναμενόμενο χρόνο ζωής του.

Και μέσα στο catch τι θα κάνεις;

Edit: όπως είπα κατά την άποψή μου εδώ δεν τίθεται καν θέμα exception αλλά επειδή ήδη συζητιέται, έχω μια απάντηση στο stack overflow εδώ. Η ερώτηση ήταν για PHP, η απάντηση είναι γενική.

εντυπωσιακό προφίλ στο stack overflow. συγχαρητήρια 

[tsofras]

Στο δικό σου παράδειγμα θα πήγαινα με τον πρώτο τρόπο.

Έτσι έχεις την ελευθερία, αν έχεις κάνει ενα καλό σχεδιασμό να έχεις σε μια πλευρά την bussiness λογικη , και να υλοποιήσεις validators για κάθε διαφορετικό τρόπο που που θα καλέσει τον κώδικα σου.

Οπότε έχεις την δυνατότητα για τον ίδιο κώδικα να μπορείς να δεχθείς άλλο input από κονσόλα , web application , web service , να υλοποίησεις μοντέλα με δικαιώματα κτλ. Αλλάζοντας μόνο τους εκάστοτε validators

[marios28]

Σου αντιγράφω από net. Νομίζω είναι η πιο "σωστή" προσέγγιση.

The method to choose depends on how often you expect the event to occur.

• Use exception handling if the event doesn't occur very often, that is, if the event is truly exceptional and indicates an error (such as an unexpected end-of-file). When you use exception handling, less code is executed in normal conditions.

• Check for error conditions in code if the event happens routinely and could be considered part of normal execution. When you check for common error conditions, less code is executed because you avoid exceptions.

[defacer]

40 minutes ago, karaLRS said:

εντυπωσιακό προφίλ στο stack overflow. συγχαρητήρια 

Σ' ευχαριστώ. Να πω όμως ότι δε σημαίνει και πολλά, τέσσερις παράγοντες είναι που θεωρώ ότι παίζουν ρόλο:

1. Να το έχεις στόχο (υπήρξε μια μεγαλούτσικη χρονικά περίοδος που είχα αποφασίσει να πιάνω rep cap σχεδόν κάθε μέρα για να δω τι θα γίνει όταν μαζέψω many many internet points, φαίνεται αν δεις το διάγραμμα rep history)

2. Να έχεις πράγματα να πεις σε popular tags (αν είσαι ultra guru σε niche τεχνολογία απλά δεν γίνεται έτσι)

3. Απαντήσεις όχι όπως θα τις έδινα στον εαυτό μου αλλά με γνώμονα ότι θα τις διαβάσει κόσμος σε διαφορετικές φάσεις

4. Είναι κάτι που γίνεται σε κλίμακα ετών ακόμα κι αν είσαι ο Jon Skeet

[the other one]

5 λεπτά πριν, defacer είπε

Σ' ευχαριστώ. Να πω όμως ότι δε σημαίνει και πολλά, τέσσερις παράγοντες είναι που θεωρώ ότι παίζουν ρόλο:

1. Να το έχεις στόχο (υπήρξε μια μεγαλούτσικη χρονικά περίοδος που είχα αποφασίσει να πιάνω rep cap σχεδόν κάθε μέρα για να δω τι θα γίνει όταν μαζέψω many many internet points, φαίνεται αν δεις το διάγραμμα rep history)

2. Να έχεις πράγματα να πεις σε popular tags (αν είσαι ultra guru σε niche τεχνολογία απλά δεν γίνεται έτσι)

3. Απαντήσεις όχι όπως θα τις έδινα στον εαυτό μου αλλά με γνώμονα ότι θα τις διαβάσει κόσμος σε διαφορετικές φάσεις

4. Είναι κάτι που γίνεται σε κλίμακα ετών ακόμα κι αν είσαι ο Jon Skeet

 

τελικά τι έγινε;

σου στειλε ποτέ κανάς recruiter πχ επειδή τσέκαρε τυχαία το profile σου;

[defacer]

1 hour ago, the other one said:

τελικά τι έγινε;

σου στειλε ποτέ κανάς recruiter πχ επειδή τσέκαρε τυχαία το profile σου;

Recruiters δεν κοιτάνε εκεί, αλλά υπάρχει το stack overflow careers όπου ναι, σε βρίσκουν συχνά όταν βάζουν ανάλογες καταχωρήσεις.

Η αυξημένη ορατότητα όμως και μετά το πλούσιο προφίλ από πίσω σημαίνει πως όταν είσαι ενεργός έρχονται προτάσεις από κόσμο: word of mouth recruiting, contract συνεργασίες συμβουλευτικές και μη, ερωτήσεις κάθε είδους, people saying hi, από εκεί μπορείς να δικτυωθείς λίγο "for free", τέτοια πράγματα.

Επί της ουσίας, έχω μεταναστεύσει στο Βερολίνο εδώ και μερικά χρόνια, έχοντας ήδη αυτή τη συγκεκριμένη προτίμηση πολύ βολικά η πρώτη μου δουλειά εδώ αλλά και μερικές που τελικά δεν προτίμησα με βρήκαν μόνες τους όταν, όπως είχα δει νωρίτερα να κάνουν άλλοι, έγραψα στο bio είμαι πρόθυμος ελάτε σε επαφή. Nice but not life changing, αιτήσεις μπορεί να κάνει κανείς και χωρίς προφίλ, και πέρα από την πρώτη επαφή δεν αλλάζει κάτι στη διαδικασία.

2 hours ago, the other one said:

Αυτό θα μπορούσε να ειπωθεί αντίστροφα αναλόγως με το τι θα θεωρούσε κάποιος "meaningful".

Μπορείς ακόμα και να πεις ότι είναι κάτι τόσο γενικό που δε σημαίνει τίποτα, και από μόνο του δε θα είχες πολύ άδικο.

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

Η δική μου πρόθεση ήταν φεύγοντας από εκεί να σου έχει μείνει μια γενική αίσθηση κατανόησης ενός θέματος με τεράστιο εύρος, υποστηριγμένη με κάποια απλά παραδείγματα για σημεία αναφοράς. Δεν έχει νόημα να μιλήσω για πιο προχωρημένα σενάρια με λεπτομέρειες, αυτοί που φτιάχνουν τέτοια σενάρια δεν είναι το κοινό της ερώτησης που διατυπώθηκε οπότε το να εστιάσω εκεί θα ήταν λίγο missing the point.

ΥΓ για το rep που λέγαμε, αυτή η απάντηση είναι μία μόνο ζωντανή απόδειξη (έχω δει αμέτρητες από άλλους χρήστες) πως καλό το technical skill αλλά αν θες να μαζέψεις νούμερα τα ας τα πούμε writing skills μετράνε εξίσου πολύ ή και περισσότερο.

Επεξ/σία 8 Ιουλίου 2018 από defacer

[Lanike71]

3 ώρες πριν, defacer είπε

Όταν έχεις την επιλογή "να μη το άφησεις να συμβεί" τότε δε μιλάμε για χειρισμό σφαλμάτων. Τα σφάλματα εξ ορισμού δε μπορείς να μη τα αφήσεις να συμβούν. Οπότε θα έλεγα η ερώτηση όπως διατυπώθηκε είναι λίγο red herring.τον αναμενόμενο χρόνο ζωής του.

 

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

Επειδή μπορεί να τύχει η περίπτωση που να χρειάζεται, πριν απ' όλα, να κάνεις κάποια συγκεκριμένα πράγματα για να κάνεις κάποια δουλειά μέσω gui, μήπως είναι απωθητικό για το χρήστη το να δει όλα τα components εκτός κάποιου να είναι μη επιλέξιμα (γκριζαρισμένα);

Θα σου δώσω παράδειγμα :

Έχεις μία φόρμα που ζητείται όνομα,επίθετο, διεύθυνση,τηλέφωνο,mail και ξέρεις ότι το επίθετο είναι απαραίτητο για να γίνει εγγραφή. Γιατί να μη γίνουν εξ' αρχής όλα μη επιλέξιμα εκτός του πεδίου "επίθετο" και μόλις κάνεις εισαγωγή του επιθέτου να σου δώσει δικαίωμα να συνεχίσεις, αλλά (αυτό που βλέπω τώρα να γίνεται) να τα δίνει επιλέξιμα όλα και δίπλα στο επίθετο να έχει αστερίσκο και να δίνει οδηγίες τύπου "πεδίο απαραίτητο";

[παπι]

4 ώρες πριν, defacer είπε

Και μέσα στο catch τι θα κάνεις;

Προσκοπικά βαζω ενα try για ολα τα uncatched, και μεσα σε αυτο απλα κανω dump το exception σε ενα αρχειο έπειτα ζητάω restart της εφαρμογής. Αν και χαζο, κάνει δουλειά.

Επεξ/σία 8 Ιουλίου 2018 από παπι

[defacer]

10 hours ago, Lanike71 said:

Γιατί να μη γίνουν εξ' αρχής όλα μη επιλέξιμα εκτός του πεδίου "επίθετο" και μόλις κάνεις εισαγωγή του επιθέτου να σου δώσει δικαίωμα να συνεχίσεις, αλλά (αυτό που βλέπω τώρα να γίνεται) να τα δίνει επιλέξιμα όλα και δίπλα στο επίθετο να έχει αστερίσκο και να δίνει οδηγίες τύπου "πεδίο απαραίτητο";

Τώρα δε σκέφτεσαι σα χρήστης αλλά σαν τεχνικός.

Για το χρήστη το πιο σημαντικό πράγμα (εκτός από το να ξεμπερδεύει με τις βλακείες που τον αναγκάζουμε να κάνει για να γίνει η δουλειά του) είναι η εμπειρία του να είναι προφανής και προβλέψιμη. Η ένδειξη από δίπλα, χωρίς να είναι το καλύτερο πράγμα που έχει εφευρεθεί ποτέ, έχει αυτά τα δύο χαρακτηριστικά.

Στο παράδειγμά σου ένα μεγάλο πρόβλημα είναι ότι δεν είναι προφανές για το χρήστη πώς λειτουργεί η φόρμα. Αν το σκεφτείς τον βάζουμε να κάνει trial and error και επιβεβαίωση της θεωρίας που μπορεί να έχει όσον αφορά το τι θα γίνει αν αρχίσει να συμπληρώνει. Όχι συνειδητά, αλλά αυτή είναι η ουσία.

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

Θα πρέπει να φτάσουμε σε σημείο τεράστιας εξειδίκευσης των χρηστών και της διαδικασίας για να μπορούμε να μιλάμε για υπεροχη κάποιας custom κατάστασης απέναντι στο κλασικό μοντέλο φόρμας, με το οποίο οι πάντες είναι λίγο πολύ εξοικειωμένοι. Think QWERTY vs Dvorak.

Τέλος, μη ξεχνάς ποτέ πως όταν αποφασίζεις να βάλεις το τρένο σε ράγες, you better be very sure πως όλοι θέλουν να πάνε από την ίδια διαδρομή (ή τουλάχιστον όλοι οι υποψήφιοι πελάτες σου). Τι θα γίνει αν ο consumer της φόρμας δεν είναι άνθρωπος, αλλά π.χ. κάποιο autofill? Για μένα θα έπρεπε να υπάρχουν τεράστια πλεονεκτήματα στην περίπτωση του ανθρώπου προκειμένου να δικαιολογηθεί το "σαμποτάζ" των άλλων consumers και η δουλειά που θα χρειαστεί για να υλοποιηθεί.