Visual Basic Try Catch

[Spect~]

εχω μια εργασια για τη σχολη και εχω μια απορια σχετικα με try catch.

 

Θελουμε νε δεχομαστε input νουμερα και να το κανουμε αυτο οσο η εισοδος δεν ειναι 0.

 

Θελουμε ταυτοχρονα να ελεγχουν οτι η εισοδος ειναι νουμερο και οχι κατι χαρακτηρες αλλα πρεπει να γινει με try catch.

 

εχω κατι του στυλ 

 

While (user_input <> 0)

Try
                user_input = InputBox(message, title)
 

            Catch ex As Exception
 
                user_input = InputBox(message, title)
            End Try

 

End While

 

ολα δουλευουν οκ εκτος απο την περιπτωση που δωσουμε δυο συνεχομενες φορες λαθος εισοδο. Υπαρχει τροπος ωστε αμεσως μετα το catch να επιστρεψει πισω στο Try code?

 

Ο μονος τροπος που σκεφτηκα για να δουλεψει ειναι μπακαλιστικος ο οποοις με μια while μεσα στο catch statement δεχεται εισοδο μεχρι να δοθει αριθμος αλλα ετσι ουστιαστικα ακυρωνεται το try catch που θελει ο καθηγητης.

 

Καμια ιδεα?

[AllCowsEatGrass]

Κατ' αρχήν, εφ' όσον το case (bad user input)  μπορεί να γίνει handle με κώδικα, δεν υπάρχει κανένας απολύτως λόγος να το κάνεις με Try Catch. Παρ όλα αυτάλ, χοντρικά
 

While (user_input <> 0)
Try
                user_input = InputBox(message, title)
 
            Catch ex As Exception
                handle_exc(ex)

                Continue While
            End Try
 
End While

Γενικά δεν είναι σωστό να κάνεις catch το base class Exception. Γενικά, δεν είναι σωστό να γράφεις VB

[Spect~]

Κατ' αρχήν, εφ' όσον το case (bad user input)  μπορεί να γίνει handle με κώδικα, δεν υπάρχει κανένας απολύτως λόγος να το κάνεις με Try Catch. Παρ όλα αυτά.

 

While (user_input <> 0)
Try
                user_input = InputBox(message, title)
 
            Catch ex As Exception
                handle_exc(ex)

                Continue While
            End Try
 
End While

Γενικά δεν είναι σωστό να κάνεις catch το base class Exception. Γενικά, δεν είναι σωστό να γράφεις VB

ναι εγω το ξερω οτι δεν χρειαζεται try catch αλλα ετσι το θελει με μια λουπα ειναι πολυ πιο ευκολο και απλο

 

και επισης πηρα αυτο το μαθημα απλα επειδη πρεπει να συμπληρωσω ECTS απο general studies courses και δεν ηθελα να παρω κατι αλλο που θελει διαβασμα

[Spect~]

τελικα αυτο που εκανα ηταν να θεσω το User_input = -1 στο  catch ετσι ωστε οταν επεστρεφε στη λουπα δεν ειχα ερρορ!!!

[Apoll]

 

Γενικά δεν είναι σωστό να κάνεις catch το base class Exception. Γενικά, δεν είναι σωστό να γράφεις VB

 

Για μισό ρε φίλε, μια χαρά γλώσσα είναι, ιδίως μετά την έκδοση 10. Γιατί ο ρατσισμός;;;;;;

Και τo continue While, είναι λάθος τρόπος για να κάνεις χειρισμό ενός exception και να επιστρέψεις στο loop, ανεξάρτητα αν είναι VB ή C#. Και κατ αρχήν στην .ΝΕΤ έκδοση δεν χρειάζεται, αν ο κώδικας στο catch δεν σηκώνει exception. Θα φτάσει στο end try και θα εκτελέσει το End While που θα συνεχίσει το  loop.

 

 

τελικα αυτο που εκανα ηταν να θεσω το User_input = -1 στο  catch ετσι ωστε οταν επεστρεφε στη λουπα δεν ειχα ερρορ!!!

 

Δεν ξέρω τί κάνει ο κώδικά σου, αλλά αυτή η λογική δημιουργεί bugs και ένα loop το οποίο μπορεί να συναντήσει ένα σορώ διαφορετικού τύπου exception και θα συνεχίσει να εκτελεί την εφαρμογή. Γιατί το user_input δεν θα έπρεπε να αλλάζει ποτέ στον κώδικα εκτός όταν αυτό εισάγει ο χρήστης.

 

Αν ο κώδικάς σου είναι αυτός.

While (user_input <> 0)

Try
                user_input = InputBox(message, title)
 

            Catch ex As Exception
 
                user_input = InputBox(message, title)
            End Try

 

End While

Το πρόβλημά σου βρίσκεται στην μέθοδό  InputBox(message, title) και στην λογική που ακολουθείς.

Γιατί αν σήκωσε Exception στην πρώτη περίπτωση θα το κάνει ΚΑΙ μέσα στο catch. Το οποίο φυσικά αφού δεν βρίσκεται σε Try block, θα σηκώσει Application Exception και θα κρασάρει.

 

Οπότε στο Catch block, δεν εκτελείς τον κώδικα που σου βαράει, όπως έγραψε και ο "Όλες οι Αγελάδες τρώνε γρασίδι" αλλά αυτόν που θες εσύ. Μπορείς φυσικά να το αφήσεις και κενό, αν δεν θες να κάνεις χειρισμό του exception, και να πας κατευθείαν στην end try.

Και σε VB.ΝΕΤ τουλάχιστον, θα σου εκτελέσει το End While και θα ξαναρχίσει το loop.

 

Σημείωση μη έχωντας όλη την λογική της εφαρμογή σου, μπορείς να ξεφύγεις από το loop και να μην το έχεις καθόλου σε .ΝΕΤ αν γράψεις διαφορετικά τον κώδικα από την αρχή.

[Spect~]

αν και οπως ειπα το τελειωσα και την εχω ηδη παραδωσει.

 

Αναγκαστηκα θα πρεπει να αλλαξει το input σε μια τιμη η οποια θα επιστρεψει στο try block και θα συνεχισει το προγραμμα χωρις να το επηρεασει. Αν δεν αλλαξω μεσα στο catch block το Input την στιγμη που επιστρεψει στο try block θα βαρεσει error γιατι θα παει να ελεγξει στην while αν καποιο string εναι ισο με το 0 το οποιο και θα τερματησει την εφαρμογη.

 

Οπως ειπα και πριν το μαθημα το πηρα γιατι επρεπε να συμπληρωσω μοναδες και πραγματικα δεν με καιει να μαθω και VB μιας και μου φαινεται αρκετα εκνευρηστικη και αδιαφορη!

[Apoll]

αν και οπως ειπα το τελειωσα και την εχω ηδη παραδωσει.

 

Αναγκαστηκα θα πρεπει να αλλαξει το input σε μια τιμη η οποια θα επιστρεψει στο try block και θα συνεχισει το προγραμμα χωρις να το επηρεασει. Αν δεν αλλαξω μεσα στο catch block το Input την στιγμη που επιστρεψει στο try block θα βαρεσει error γιατι θα παει να ελεγξει στην while αν καποιο string εναι ισο με το 0 το οποιο και θα τερματησει την εφαρμογη.

 

Οπως ειπα και πριν το μαθημα το πηρα γιατι επρεπε να συμπληρωσω μοναδες και πραγματικα δεν με καιει να μαθω και VB μιας και μου φαινεται αρκετα εκνευρηστικη και αδιαφορη!

 

Δεν είναι η VB τότε, αλλά ο προγραμματισμός γενικά. Γιατί η C# θα σου δώσει και επιπλέον warning άμα τα κάνεις αυτά.

[AllCowsEatGrass]

Η VB είναι μία χαρά γλώσσα, αν θέλεις να κινηγάς runtime errors και ευφάνταστα λογικά λάθη. Δεν θέλω να ξεκινήσω να γράφω σεντόνια για τη VB αλλά μια χαρά δε τη λες, σίγουρα έχει κι αυτή τη θέση της κάπου...αλλά it sucks....big time. Χαρακτηριστικά: 

Εφ' όσον αυτό κάνει compile, και σκάει

 Dim i = 10
 i = "!"

ή ότι αυτό εν τέλη κάνει assign στο flag2 True, με φαντασία

Dim flag1 = False
Dim flag2 = False

flag2 = flag1 = False

ή ότι αυτό κάνει eval σε True, γιατί ελέγχει αν ο Integer είναι 0

Dim i = 0
If i <> Nothing ...

ή το γεγονός οτι δεν έχει inline assignment, και γενικά τα τα keywords Fuction και Sub στην χρήση τους για "lambda"...δεν την καθιστούν μία χαρά.

Θα μπορούσε να πει κανείς πως όλα αυτά τα ξέρεις ή οφείλεις να τα ξέρεις, ή στην τελική έτσι δουλεύουν τα πράγματα στη VB. Ισχύει, αν είναι να γράφεις μία ζωη VB, αλλά το transition σε άλλη γλώσσα είναι οδυνηρό. Φιλικά. 

ΥΓ:    Υπάρχει και το Option Strict On, αλλά οι γερόλυκοι της VB το θεωρούν too much. 
ΥΓ 2: Μιλάω για VB.Net, αν κάτι δεν ισχύει για plain VB my bad.

[Apoll]

Γράφω και στις 2 γλώσσες για πάνω από δεκαετία τώρα.

Γράφωντας σωστά ακολουθώντας το σωστό συντακτικό, δεν είχα κανένα πρόβλημα με την VB. Και το Option Strict On είναι απαραίτητο μόνο όταν γράφεις κώδικα όπως ο δικός σου το παράδειγμά σου.

[defacer]

Ε ναι, χωρίς option strict on συγκρίνουμε μήλα με πορτοκάλια. Αν είναι και στη C# να κάνουμε τα πάντα dynamic και να πούμε ότι φταίει η γλώσσα γι' αυτό που θα συμβεί.

[AllCowsEatGrass]

@Def μαζί σου, καλό το option strict on, αλλά δε τα λύνει και όλα.
 

Option Strict On

Class Class A
   Public Property Name As String
End Class

.
.
.

Dim aList = New List(Of ClassA)()

aList.ForEach(Sub(x) x.Name = x.Name.Trim())

aList.ForEach(Function(x) x.Name = x.Name.Trim())

Κάνε debug μία η ώρα αυτό το πράμα, γιατι δεν κάνει trim... Και δεν ήταν τόσο απλό, αυτό είναι απλά για το point. Γενικά αν έχεις επιλογή δεν αξίζει ν ασχολιθείς, πάντα η ταπεινή μου άποψη.

[Apoll]

@Def μαζί σου, καλό το option strict on, αλλά δε τα λύνει και όλα.

 

Option Strict On

Class Class A
   Public Property Name As String
End Class

.
.
.

Dim aList = New List(Of ClassA)()

aList.ForEach(Sub(x) x.Name = x.Name.Trim())

aList.ForEach(Function(x) x.Name = x.Name.Trim())

Κάνε debug μία η ώρα αυτό το πράμα, γιατι δεν κάνει trim... Και δεν ήταν τόσο απλό, αυτό είναι απλά για το point. Γενικά αν έχεις επιλογή δεν αξίζει ν ασχολιθείς, πάντα η ταπεινή μου άποψη.

 

Γράφεις ΠΟΛΥ άσχημο κώδικα σε VB για να αποδείξεις ότι έχεις δίκιο;;;;;;

[AllCowsEatGrass]

Το foreach σε λίστα είναι ασχημος κώδικας; Πως να κανω iterate τη λίστα δηλαδή, με counters και for loops; 

[defacer]

Κοίτα, και γω δεν την έχω σε μεγάλη υπόληψη τη VB αλλά βασικά τα παραδείγματά σου είναι απλά "λάθος κώδικας"

 

aList.ForEach(Function(x) 
        x.Name = x.Name.Trim()
End Function)

Αυτό δουλεύει μια χαρά.

 

Σα να λέμε τώρα γιατί δε δουλεύει σωστά αυτό

 

var fs = new List<Action>();
for (var i = 0; i < 10; ++i) {
    fs.Add(() => Console.WriteLine(i));
}
    
fs.ForEach(d => d());

Δε δουλεύει σωστά γιατί δεν το έχεις γράψει σωστά. Δε φταίει η ForEach ούτε κανένας άλλος.

[AllCowsEatGrass]

 

Κοίτα, και γω δεν την έχω σε μεγάλη υπόληψη τη VB αλλά βασικά τα παραδείγματά σου είναι απλά "λάθος κώδικας"

 

aList.ForEach(Function(x) 
        x.Name = x.Name.Trim()
End Function)

Αυτό δουλεύει μια χαρά.

Αυτό που έχεις γράψει δεν κάνει compile με Option Strict On, πρέπει να το κάνεις Sub, που είναι το σωστό, γιατί το Function θέλει Return statement, νομίζω Ι proved my point. 

 

Για αυτό περίπου το λόγο δεν κάνει trim στο παραδειγμά μου το for each με το Function, κάνει return Boolean επειδή είναι function με ένα statement και ο assign είναι ίδιος με τον equals, οπότε καλεί τον equals

 

Νομίζω είναι moot point το οτι γράφω κακό κώδικα. Αν πέσει ένα legacy codebase από VB στα χέρια σου θα δεις πολύ χειρότερα πράματα, τα οποία πρέπει να καταλάβεις τι κάνουν πριν κάνεις refactor. Αυτό που θέλω να πω είναι πως δεν σε βοηθάει η γλώσσα να προσέξεις αυτά που γράφεις, είναι μέσα στα pitfalls.

 

Παρόλα αυτά, συμφωνώ με ότι λες, προφανώς δεν φτέει ουτε η ForEach ούτε η VB, κακός κώδικας υπάρχει παντού όμως.

 

edit: +1 για το lambda μέσα σε loop. Αλλά το δικό μου παράδειγμα θα μπορούσε να πιαστεί compile time. Το ForEach παίρνει action, για ποιο λόγο να μην σκάει αμα του περνάς Function;