.NET Framework

Απ: C# ή VB.NET ?

sakalis — Thu, 13 Dec 2012 20:44:21 GMT

BruteForce:

Σίγουρα κάνει pay back το testing. Απλά μερικοί άνθρωποι δεν νοιάζονται για τις μετέπειτα συνέπειες επειδή πολύ απλά δεν σκοπεύουν να είναι στην εταιρία όταν θα σκάσουν αυτές οι συνέπειες. Άρα νοιάζονται μόνο για τα short term benefits.
Αυτόν τον παράγοντα ελάχιστοι τον σκέφτονται ;-)

Το θέμα δεν ειναι μόνο οι συνέπειες στο μέλλον. ΤΟ θέμα ειναι ότι με τα unit test μειώνεις και τον χρόνο του development, μειώνεις τα ξενύχτια στο τέλος του deadline μειώνεις το άγχος κτλ κτλ. Επομένως οι παραπάνω δεν νοιάζονται ούτε για τα short term benefits

Απ: C# ή VB.NET ?

Tsopi — Tue, 11 Dec 2012 23:06:08 GMT

Ok, συμφωνώ μαζί σου. Όμως όταν έχω χιλιοπαιδευτεί όπως σου είπα πιο κάτω για ένα backup αρχείο, πραγματικά δεν έχω όρεξη να ασχοληθώ με κάτι σχεδόν απίθανο και για εμένα ασύμαντο. Μιλάμε για την συνάρτηση που εμφανίζει τον χρόνο αναπαραγωγής! Δηαδή το να πάρεις ένα seconds σε integer και να το μετατρέψεις σε ταμπελίτσα του στυλ 12:30 . Ο κώδικας είναι τόσο απλός και καθαρός, τα datatypes είναι ηλιθιοδώς μεγάλα ( έχω βάλει int64 για τα seconds) που για κάνει ένα overflow πρέπει να το χρησιμοποιήσει ο τσάκ νόρις. Οκ, να βάλω να ελέγχει το πρόβλημα...αλλά ποιο πρόβλημα ακριβώς να πιάσω?

Να βάλω Try Catch και να ελένξω τι? Να πέσει αρνητικός αριθμός? Παρόλο που έχω βάλει int64 και οχι uint64 ( μπας και συμβεί ποτέ κάτι), αυτό σημαίνει πως κάτι στο windows media player δεν λειτουργεί σωστά ( επειδή χρησιμοποιώ αυτό το component ) . Και τι υποτήθεται πως πρέπει να κάνω για αυτό? Πως να αναπαραγάγω αυτό το πρόβλημα για να δώ πως να το αντιμετωπίσω?

Να ελένξω το overflow? Δηλαδή οκ , αν κάνεις overflow σε int64 μιλάμε πως έχεις βάλει τραγούδι να παίζει για 292271023045 χρόνια! ok... δεν με νοιάζει... πρόβλημα του χρήστη!

Απ: C# ή VB.NET ?

BruteForce — Tue, 11 Dec 2012 20:31:34 GMT

Tα code contracts... άλλο ένα syntactic sugar της MS. Το μισό .ΝΕΤ είναι syntactic sugar τελικά. Ναι αυτή είναι η λογική με αυτά τα contracts. Να ελέγχεις τα pre/post conditions.

Το Test Driven Development στην πράξη είναι δύσκολο, γιατί όταν η κλάση δεν υπάρχει, δεν ξέρεις και τι κάνει, οπότε πώς θα την τεστάρεις;;;
Εγώ έχω εφαρμόσει αυτό που ονομάζω "Test Targeted Development", δηλαδή development που φτιάχνει testable modules. Και φυσικά μπαίνω στον κόπο να γράψω και τα tests ή να βάζω άλλους να τα γράψουν. Τώρα που κάνω κουμάντο εγώ, το testing είναι βασικό κομμάτι του development, όχι μία προαιρετική δραστηριότητα.

Σίγουρα κάνει pay back το testing. Απλά μερικοί άνθρωποι δεν νοιάζονται για τις μετέπειτα συνέπειες επειδή πολύ απλά δεν σκοπεύουν να είναι στην εταιρία όταν θα σκάσουν αυτές οι συνέπειες. Άρα νοιάζονται μόνο για τα short term benefits.

Αυτόν τον παράγοντα ελάχιστοι τον σκέφτονται ;-)

Θα σου γράψω άλλη ώρα για τα static.

Απ: C# ή VB.NET ?

xabikos — Tue, 11 Dec 2012 08:42:55 GMT

Αρχικά να σε ευχαριστήσω για τον κόπο σου μιας και εγώ ζήτησα το παράδειγμα για να καταλάβω τι ακριβώς εννοείς.
Δουλεύω ως επαγγελματίας .ΝΕΤ developer 3+ χρόνια οπότε έχω πολλά να μάθω ακόμη και κάθε συμβουλή από ποιο έμπειρους συναδέλφους είναι πολύτιμη και προσπαθώ να την καταλάβω και να την εκτιμήσω.

Το συγκεκριμένο παράδειγμα είναι εκτενές και πλήρες και έπιασα το βασικό νόημα, αν και είναι δύσκολο να το ακολουθήσω πλήρως μιας και δεν έχω καθόλου εμπειρία με T-SQL. Έχω δουλέψει μόνο με ORMs οπότε δεν υπήρξε ανάγκη για SQL μέχρι τώρα. Ξέρω ότι πρέπει να γνωρίζω και SQL ως προγραμματιστής αλλά αυτό είναι θέμα για άλλη συζήτηση μάλλον.

Για να σχολιάσω το παράδειγμα απλά μου φαίνεται λογικό να θέλει πάρα πολλούς ελέγχους το συγκεκριμένο μιας και είναι ειδική περίπτωση. Σε περίπτωση που είχαμε C# κώδικα και αφού υποθέσουμε ότι ακολουθούμε τις γνωστές αρχές ότι κάθε μέθοδος πρέπει να είναι υπεύθυνη μόνο για μία λειτουργία και συνήθως λίγες γραμμές κώδικα τότε ένας παρόμοιος έλεγχος δεν είναι πολύ δύσκολος και μπορούμε να εκμεταλλευτούμε τα code contracts που υπάρχουν γι αυτήν ακριβώς την δουλειά. Επίσης αν υποθέσουμε ότι κάνουμε Test Driven Development τότε θα πρέπει πρώτα να γράφουμε όλα τα unit tests που εννοείται περικλείουν όλες τις πιθανές περιπτώσεις και με exceptions και στην συνέχεια γράφουμε τον κώδικα για να περάσουν αυτά τα τεστ. Βέβαια και πάλι να γράψουμε τεστ για όλες τις περιπτώσεις είναι δύσκολο και συνήθως χρονοβόρο κάτι που δεν είναι αποδεκτό από το project management αν και είμαι πεπεισμένος πως κάνει pay back ειδική στην συντήρηση του κώδικα από ανθρώπους που δεν τον έγραψαν.

Αυτό που θα είχε μεγαλύτερο ενδιαφέρον για μένα θα ήταν ένα παράδειγμα σχετικά με τις static functions σε C# και πως αυτό θα μπορούσε να κάνει τον κώδικα μας πιο ασφαλή. Είναι μια τεχνική που δεν μπόρεσα να σκεφτώ πως λειτουργεί. Αλλά δεν μπορώ να ζητήσω ξανά κάτι μιας και ήδη έδωσες ένα παράδειγμα για το τι εννοούσες.

Απ: C# ή VB.NET ?

BruteForce — Tue, 11 Dec 2012 00:09:02 GMT

Κάποιοι στην κουβέντα ζητήσανε παραδείγματα.

Επειδή το συγκεκριμένο που ζητήθηκε θεωρώ ότι είναι πολύ απλό και αυτονόητο, σας δίνω ένα παράδειγμα error checking/handling σε κώδικα T-SQL.

Και από αυτό φανταστείτε τι γίνεται στην C#.

Απλά αντί για RAISERROR πέφτουν βροχή τα throw InvalidParameterException και όταν ο caller έχει κάπου bug και κάποια στιγμή κάνει invalid call το πιάνουμε αμέσως και το λύνουμε σε 30 δευτερόλεπτα.

Η τακτική που ακολουθώ πάντα είναι ότι ο έλεγχος των παραμέτρων είναι εξαντλητικός σε όλα τα "Boundaries".

Όταν ο κώδικας C# καλεί κώδικα SQL, τότε περνάμε ένα boundary, άρα θέλει εξαντλητικό έλεγχο.

Οι public methods μιας κλάσης είναι boundary.

Άρα θέλει εξαντλητικό έλεγχο και εκεί, κοκ.

Στις άλλες περιπτώσεις γίνεται απλός έλεγχος παραμέτρων με βάση την κοινή λογική και με ολίγη από Debug.Assert.

Όπως βλέπετε παρακάτω, πέρα από τις παραμέτρους, και ΚΑΘΕ statement SQL που πειράζει τη βάση ελέγχεται και βγαίνει custom μήνυμα λάθους ώστε να έχω πλήρη πληροφόρηση για το τι παίχτηκε.

Θα μπορούσα με BEGIN TRY να τα κάνω στον μισό κώδικα, αλλά μετά θα έπαιρνα ότι error message προαιρείται ο SQL server και θα ψαχνόμουν στο άπειρο.

Και σιγά μην μου έβαζε μέσα στο μήνυμα το ProcessId ή άλλες χρήσιμες πληροφορίες που μπορεί να θέλω.

Δεν χρησιμοποιώ BEGIN TRY, παρά μόνο στα upgrade scripts των βάσεων.

Μου χάλασε λίγο τη στοίχηση το copy paste, αλλά μπορείτε να δείτε ότι όλα τα error checking είναι ένα tab πιο μέσα, ώστε να μην μπερδεύονται με τον υπόλοιπο κώδικα.

Επίσης το section με τα αρχικά parameter checks ξεχωρίζει από το main body με σχόλια, ώστε γρήγορα να βρίσκω αυτό που θέλω.

Όπως βλέπετε έχει πολύ κόπο το πλήρες error checking/handling και θέλει πολύ υπομονή.

Αλλά κάθε βράδυ κοιμάμαι ύσηχος :-)

Α ναι, και μην ξεχνάτε να ελέγχετε στις stored procedures αν υπάρχει transaction :-)

Το τι γίνεται όταν ο caller "ξεχάσει" να ξεκινήσει transaction και σκάσει κάποιο λάθος στην SQL έχει πάρα πολύ "πλάκα".

Είναι από τα αγαπημένα μου horror movies.

Γι'αυτό και το συγκεκριμένο είναι και ένα από τα αυτοματοποιημένα μας test.

Enumerate all strprocs και κλήση τους με όλες τις παραμέτρους null και χωρίς transaction.

Αν δεν γίνει fail με το σωστό error message, τότε έχουμε bug.

Επίσης παρατηρήστε τη χρήση των "database enums" ώστε ο κώδικας να είναι και περισσότερο αναγνώσιμος.

Είναι απλές SQL Functions του ενός statement. Η μία return 1, η άλλη return 2, κ.ο.κ.

Κάντε μου και ένα free code review μήπως υπάρχει και κανα bug ;-)

CREATE PROCEDURE dbo.InsertAction
	@a_ProcessId		int,
	@a_ActionKindId		int,
	@a_NewActionId		int OUTPUT
WITH ENCRYPTION AS
BEGIN
	SET NOCOUNT ON
	
	/***************************************************
					Parameter Validations
	 ***************************************************/
	-- Make sure everything is transactional no matter how we were called
	IF (@@TRANCOUNT = 0)
	BEGIN
		RAISERROR('Invalid call. Transaction required', 11, 0) WITH SETERROR
		RETURN
	END


	--------------------------
	-- Check for NULLs
	--------------------------
	IF ((@a_ProcessId IS NULL) OR (@a_ActionKindId IS NULL))
	BEGIN
		RAISERROR('Invalid parameter. Process or ActionKind Id is NULL', 11, 0) WITH SETERROR
		RETURN
	END


	-- Check that the process exists and is not cancelled or completed
	DECLARE @ProcessState tinyint
	SELECT @ProcessState = ProcessState
	FROM Processes WITH (UPDLOCK, ROWLOCK)
	WHERE (ID = @a_ProcessId)
	
	IF (@@ROWCOUNT = 0)
	BEGIN
		-- We checked the Process Id is non-null so this means it is invalid.
		RAISERROR('Invalid parameter. Process %d does not exist', 11, 0, @a_ProcessId) WITH SETERROR
		RETURN
	END


	IF (@ProcessState IN (dbo.ProcessState_Completed(), dbo.ProcessState_Cancelled()))
	BEGIN
		RAISERROR('Process %d is not in a state that allows actions to be inserted.', 11, 0, @a_ProcessId) WITH SETERROR
		RETURN
	END


	-- Make sure the process is locked
	IF (dbo.fn_ProcessIsLocked(@a_ProcessId) = 0)
	BEGIN
		RAISERROR('Process %d is not locked.', 11, 0, @a_ProcessId) WITH SETERROR
		RETURN
	END


	-- Pick up the stuff we need from Action Kind
	DECLARE @SubProcessKindId int, @Title nvarchar(100), @Duration int, @Desc nvarchar(400), @DepartmentId int
	SELECT @Title = Title, 
		   @Desc = [Description], 
		   @DepartmentId = DepartmentId, 
		   @Duration = Duration,
		   @SubProcessKindId = SubProcessKindId
	FROM ActionKinds
	WHERE (ID = @a_ActionKindId)


	IF (@@ROWCOUNT = 0)
	BEGIN
		-- We checked the ActionKind Id is non-null so this means it is invalid.
		RAISERROR('Invalid parameter. ActionKind %d does not exist', 11, 0, @a_ActionKindId) WITH SETERROR
		RETURN
	END

	/***************************************************
					Do the useful work now
	 ***************************************************/
	-- Insert the action detail
	INSERT INTO ActionDetails(Title, [Description])
	VALUES (@Title, @Desc)


		IF (@@ERROR <> 0)
		BEGIN
			RAISERROR('FAILED to insert Action Detail.', 11, 0) WITH SETERROR
			RETURN
		END


	DECLARE @ActionDetailId int
	SET @ActionDetailId = @@IDENTITY
	-- Insert Action
	INSERT INTO Actions WITH (ROWLOCK)
		(
			ProcessId, PKAKId, ActionKindId, ActionDetailId,
			ActionState, ActualStartDate, Duration,
			ActualEndDate, AssignedDepartmentId, AssignedEmployeeId, SortOrder,
			-- We need to set these to a non-default value coz otherwise the
			-- UI takes a long time to reload the Gantt chart while the process
			-- is being edited.
			ExpectedStartDate, -- NORMAL_TIMESTAMP NOT NULL DEFAULT('1/1/1980'),
			ExpectedEndDate, -- NORMAL_TIMESTAMP NOT NULL DEFAULT('1/1/1980'),
			PlannedStartDate, -- NORMAL_TIMESTAMP NOT NULL DEFAULT('1/1/1980'),
			PlannedEndDate -- NORMAL_TIMESTAMP NOT NULL DEFAULT('1/1/1980'),
		)
	VALUES
		(
			@a_ProcessId, NULL, @a_ActionKindId, @ActionDetailId, 
			dbo.ActionState_Waiting(), NULL, @Duration,
			NULL, @DepartmentId, NULL, -1,
			GETDATE(), DATEADD(day, 1, GETDATE()),
			GETDATE(), DATEADD(day, 1, GETDATE()) 
		)


		IF (@@ERROR<>0)
		BEGIN
			RAISERROR('Failed to insert Action', 11, 0) WITH SETERROR
			RETURN
		END


	DECLARE @ActionId int
	SET @ActionId = @@IDENTITY
	SET @a_NewActionId = @ActionId


	-------------------------------
	-- Insert Dynamic Fields
	-------------------------------
	DECLARE DynamicFieldsCursor CURSOR FAST_FORWARD FOR 
	SELECT ActionKindDynamicFields.DynamicFieldId, 
		   DynamicFields.FieldType, 
		   DynamicFields.DefaultValue
	FROM Actions WITH (NOLOCK)
	INNER JOIN Processes WITH (NOLOCK) ON (Actions.ProcessId = Processes.ID)
	INNER JOIN ActionKinds WITH (NOLOCK) ON (Actions.ActionKindId = ActionKinds.ID)
	INNER JOIN ActionKindDynamicFields WITH (NOLOCK) ON (ActionKinds.ID = ActionKindDynamicFields.ActionKindId)
	INNER JOIN DynamicFields WITH (NOLOCK) ON (DynamicFields.ID = ActionKindDynamicFields.DynamicFieldId)
	WHERE (Actions.ID = @ActionId)


	OPEN DynamicFieldsCursor


	DECLARE @DynamicFieldId int, @FieldType int, @DefaultFieldValue money
	FETCH NEXT FROM DynamicFieldsCursor INTO @DynamicFieldId, @FieldType, @DefaultFieldValue


	WHILE (@@FETCH_STATUS = 0)
	BEGIN
		DECLARE @ValueToInsert nvarchar(80)
		SET @ValueToInsert = NULL


		SELECT  @FieldType = FieldType
		FROM DynamicFields WITH (NOLOCK)
		WHERE ID = @DynamicFieldId


		IF (@DefaultFieldValue IS NOT NULL)
		BEGIN
			IF (@FieldType IN (dbo.DynamicFieldType_Boolean(), dbo.DynamicFieldType_Enum(), dbo.DynamicFieldType_Integer()))
				SET @ValueToInsert = CONVERT(nvarchar, CONVERT(int, @DefaultFieldValue))
			ELSE IF (@FieldType = dbo.DynamicFieldType_Money())
				SET @ValueToInsert = CONVERT(nvarchar, @DefaultFieldValue)
		END


		INSERT INTO DynamicFieldValues(DynamicFieldId, ActionId, FieldValue)
		VALUES (@DynamicFieldId, @ActionId, @ValueToInsert)


			IF (@@ERROR<>0)
			BEGIN
				RAISERROR('Failed to insert into DynamicFieldValue table', 11, 0) WITH SETERROR
				RETURN
			END


		FETCH NEXT FROM DynamicFieldsCursor INTO @DynamicFieldId, @FieldType, @DefaultFieldValue
	END
	
	CLOSE DynamicFieldsCursor
	DEALLOCATE DynamicFieldsCursor


	-- Action dependencies will be handled by the caller
	-- Graph data will be handled by the caller


	/********************
		SubProcesses
	*********************/
	-- Is it a subprocess action?
	IF (@SubProcessKindId IS NULL)
		RETURN

	DECLARE @SubProcessId int, @MasterProcessId int
	SET @MasterProcessId = dbo.fn_ProcessGroupMaster(@a_ProcessId)


	-- In the normal InsertProcess procedure, the date we pass is the
	-- planned date of the action. Currently we don't have that so we
	-- will pass the current timestamp. Dates recalculation will be
	-- trigger by the caller when all changes are finished.
	DECLARE @SubProcessStartDate NORMAL_TIMESTAMP
	SET @SubProcessStartDate = GETDATE()
	EXEC InsertNewProcess @MasterProcessId, 
						  @SubProcessKindId, 
						  @SubProcessStartDate, 
						  @SubProcessId OUTPUT


		IF (@@ERROR <> 0)
		BEGIN
			RAISERROR('FAILED to insert Sub Process', 11, 0) WITH SETERROR
			RETURN
		END


	INSERT INTO ProcessRelations(MasterProcessId, ActionId, ParentProcessId, ChildProcessId)
	VALUES (@MasterProcessId, @ActionId, @a_ProcessId, @SubProcessId)


		IF (@@ERROR <> 0)
		BEGIN
			RAISERROR('FAILED to insert into ProcessRelations', 11, 0) WITH SETERROR
			RETURN
		END
END

Απ: C# ή VB.NET ?

BruteForce — Mon, 10 Dec 2012 20:42:20 GMT

Tsopi:
"γιατί να παιδευτώ", ένα από τα χαρακτηριστικά που ξεχωρίζει τους junior από τους senior developers

Όχι στην περίπτωση μου. Όταν έχω μια funtion που να εμφανίζει τον χρόνο που έχει περάσει από την αρχή του τραγουδιού σε ένα media player, "σκασίλα" μου αν κάποια στιγμή βγέι ένα οποιοδήποτε πρόβλημα και το φάει η On Error Resume Next. Δεν είναι όλα τα προβλήματα κρίσιμα και χρηματοοικονομικά...

Λάθος. Μέγα λάθος. Είναι σαν να λέει κάποιος "Εγώ είμαι ευγενικός άνθρωπος, αλλά μόνο εκεί που χρειάζεται, δεν είναι το ίδιο σπουδαίοι όλοι οι άνθρωποι ώστε να απαιτείται ευγένεια".

Το να "καταπίνει" ή να αγνοεί ο κώδικας το οποιοδήποτε λάθος, είναι... ΛΑΘΟΣ.

Είναι λάθος να αγνοείς το λάθος.

Κάνει και αναδρομικό λογοπαίγνιο.

Όποιος νομίζει ότι είναι σε θέση να κρίνει ποια λάθη έχουν σημασία και ποια όχι, είναι μάλλον πολύ νέος.

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

Ξέρεις ποιός είναι ένας από τους βασικούς λόγους που πέτυχαν τα Windows; Λόγος που διατρέχει τα τελευταία 15 χρόνια και βάλε;

H Blue Screen of Death.

Η BSOD δεν είναι crash, είναι ουσιαστικά ένα kernel message box, που σου λέει όσο πιο ευγενικά γίνεται ότι έκανες κάτι που δεν προβλέπεται, εξαιτίας κάποιου προγραμματιστικού λάθους φυσικά.

Το οποίο λάθος προφανώς ΔΕΝ μπορούσες να φανταστείς εκ των προτέρων, αλλιώς δεν θα το έκανες.

Οπότε ο kernel σου κάνει τη χάρη να μην κρασάρει αλλά να παγώσει το σύστημα ώστε να δεις τι έκανες λάθος.

Ο λόγος που ο kernel είναι τόσο ευγενικός;;;

Διότι αν το προγραμματιστικός σου λάθος αγνοηθεί, θα γίνει propagate και μετά όχι απλώς είναι βέβαιο ότι θα ακολουθήσουν νέα runtime errors, αλλά θα γίνει τέτοιος χαμός που κανείς δεν θα μπορεί να καταλάβει ποιό είναι το αρχικό λάθος.

Διότι το αρχικό λάθος είναι αυτό που φταίει συνήθως. Όπως όταν παίρνουμε έναν καταρράκτη από compilation errors στη C++.

Και μπορεί στο development PC να έχεις την πολυτέλεια να κάνεις debug, όταν όμως σαλτάρει ένας production server/PC τότε την έχεις άσχημα.

H λογική του να μην αγνοούμε τα λάθη είναι σοφή.

Όπως π.χ. το να μην αφήνεις warnings στο build, ή να αγνοείς τα false positives του lint (ή άλλων εργαλείων) και να μην τα κάνεις suppress με σχόλιο.

Μαζεύονται μετά τα άσχετα warnings και κρύβουν τα ουστιαστικά.

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

Θα μου πεις, άλλη η κρισιμότητα του kernel και άλλη ενός music player.

Συμφωνώ. Με τον kernel πρέπει να είσαι ιδιαιτέρως εξαιρετικά ευγενικός, εώς διπλωματικός.

Με ένα χρηματοοικονομικό, εξαιρετικά ευγενικός.

Με τον music player, απλά πολύ ευγενικός.

Το να αγνοείς τα λάθη είναι μέγιστη αγένεια ;-)

Τα λάθη είναι σαν τις γυναίκες.

Δεν τους αρέσει να τα αγνοούμε.

Αν το κάνουμε, they come back with a vengeance ;-)

Απ: C# ή VB.NET ?

xabikos — Sun, 09 Dec 2012 04:04:24 GMT

Πάρα πολύ ενδιαφέρουσες απαντήσεις για όλους όσους θέλουν να βελτιώνουν την ποιήτητα του κώδικα που γράφουν και να προσπαθούν να μαθαίνουν καινούρια πράγματα.
Προσωπικά όμως πάντα βρίσκω ποιο ενδιαφέρον όταν βλέπω και ένα συγκεκριμένο παράδειγμα αυτού που περιγράφεται με λόγια.
Ετσί για μένα θα ήταν πολύ ενδιαφέρον αν ο BruteForce μπορούσε να δώσει ένα παράδειγμα ειδικά για την τακτική στην C# να χρησιμοποιούμε static functions και τι πλεονεκτήματα έχει αυτό.
Δεν ξέρω βέβαια αν είναι εφικτό να δούμε κάτι τέτοιο με ένα μικρό παράδειγμα ή απαιτεί περισσότερη δουλειά.

Απ: C# ή VB.NET ?

Tsopi — Fri, 07 Dec 2012 05:56:09 GMT

"γιατί να παιδευτώ", ένα από τα χαρακτηριστικά που ξεχωρίζει τους junior από τους senior developers

Όχι στην περίπτωση μου. Όταν έχω μια funtion που να εμφανίζει τον χρόνο που έχει περάσει από την αρχή του τραγουδιού σε ένα media player, "σκασίλα" μου αν κάποια στιγμή βγέι ένα οποιοδήποτε πρόβλημα και το φάει η On Error Resume Next. Δεν είναι όλα τα προβλήματα κρίσιμα και χρηματοοικονομικά...

Και δεν βαριέμαι να γράψω κώδικα για να πιάνω τα προβλήματα. Στο ίδιο player, η funtion που αποθήκευε ένα αρχείο για backup ρυθμίσεις, είχε 15 εντολές. Όχι μόνο είχα βάλει Try Catch σε ΚΑΘΕ εντολή , αλλά είχα φτιάξει και enum για να το κάνω return ώστε να ξέρω ακριβώς που υπήρξε πρόβλημα και ποιο ήταν ( προκειμένου να το αντιμετωπίσω κατάλληλα ).

Και δυστυχώς δεν είμαι junior developer... επειδή δεν έχω βρεi δουλειά ακόμα :P

Απ: C# ή VB.NET ?

BruteForce — Thu, 06 Dec 2012 23:08:28 GMT

Good points.

Για να κάνω μια αναλογία που νομίζω είναι σχετική, ο απόλυτος παράδεισος του error handling είναι οι Database Servers.

BEGIN TRANSACTION και αν κάτι πάει στραβά ROLLBACK και όλα καθαρά και ανέγγιχτα.

Αυτό είναι τόσο βοηθητικό, που το Win32 και ο kernel των Windows, έχουν ρουτίνες για transactional handling της registry και το file system!

Στον κώδικα C++/C# όμως το handling είναι σαφώς πιο δύσκολο, γιατί ο κώδικας πρέπει να γραφτεί functional.

Συνήθως μετά από ένα error το object είναι "άχρηστο", δηλαδή δεν έχουμε ιδέα σε τι κατάσταση βρίσκεται εσωτερικά. Άρα πρέπει να το σουτάρουμε άμεσα.

Τώρα πρέπει να καταλάβουμε κάτι βασικό.

Κάθε member function που γράφει σε member variable, είναι σχεδόν σαν να γράφει σε global μεταβλητή.

Όσο πιο πολλές functions γράφουν, τόσο περισσότερο χάνεται η μπάλα.

Μια τεχνική που χρησιμοποιώ εγώ στη C#, είναι να κάνω όσο πιο πολλές member functions static, οπότε δεν μπορούν να αγγίξουν τίποτα, μόνο να δεχτούν παραμέτρους και να επιστρέψουν output. Έτσι ελαχιστοποιείται ο κώδικας που είναι σε θέση να πειράξει μια member variable.

Επίσης ελαχιστοποιούνται τα references στις member variables και όταν κάνω Find References δεν μου βγαίνει ένας καταρράκτης, άρα μπορώ να βγάλω άκρη εύκολα και να ελέγξω τι γίνεται σε κάθε σημείο που χρησιμοποιείται η member variable.

Αυτό βέβαια σημαίνει ότι μπορεί να γράψουμε λίγο κώδικα παραπάνω, γιατί διάφορες member variables θα πρέπει να τις περνάμε παραμέτρους στις static functions, αντί αυτές να τις διαβάζουν.

Η C++ είχε το εκπληκτικό feature των const member functions.

Αυτές μπορούν να διαβάσουν το state του object, αλλά ΔΕΝ μπορούν να το αλλάξουν.

Απλά ΤΕΛΕΙΟ. Και επιπλέον έχει const parameters, οπότε περνάω ένα object σαν const reference και ο κώδικας ΔΕΝ μπορεί να το πειράξει, αλλά μόνο να το διαβάσει.

Το 80% των C++ member functions στον κώδικά μου είναι const και έχω το κεφάλι μου ήσυχο.

Δυστυχώς, επειδή η C# είναι φτιαγμένη ώστε να είναι κατανοητή και από πιθήκους, δεν έχει constness σε παραμέτρους και member functions.

Οπότε ακόμα και σε static member function, αν περάσω ένα member variable που είναι List<> για παράμετρο, η static function μπορεί να του βγάλει τα μάτια.

Με κάτι τέτοια η C++ προστατεύει τους σοβαρούς προγραμματιστές, και μου επιτρέπει να γράψω κώδικα που κάποιος στο παρελθόν τον χαρακτήρισε "Φρούριο".

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

Φανταστείτε απλά, κάθε 3-4 χρόνια να απλοποιούσαν την Ιατρική όπως "απλοποιούν" το development, ώστε να έχουμε περισσότερους γιατρούς, γιατί αυτοί που έχουμε δεν φτάνουν.

Δεν θα ήταν τραγικό;;;

Απ: C# ή VB.NET ?

Παναγιώτης Καναβός — Thu, 06 Dec 2012 22:20:21 GMT

BruteForce:

H σωστή κατανόηση και σωστή χρήση των exceptions είναι κάτι που ΔΕΝ μπορεί να συλλάβει ο μέσος προγραμματιστής.
Απλά ΔΕΝ ΜΠΟΡΕΙ.

Και όχι μόνο ο μέσος προγραμματιστής. Το HttpWebRequest θα πετάξει exception είτε ζητήσεις μία σελίδα που λείπει και πάρεις 404, είτε ζητήσεις μόνο την αλλαγμένη σελίδα και πάρεις 304. Το οποίο σημαίνει ότι η σελίδα δεν άλλαξε, και δεν πρόκειται ούτε καν για error. Ευτυχώς συνήλθαν λίγο στο .ΝΕΤ 4.5 και ο HttpClient δεν σηκώνει αυτόματα exceptions ...

Θα πάω λίγο παραπέρα. Τα exception είναι απλά ένας μηχανισμός για να σε ειδοποιήσει και να σε προστατεύσει σε exceptional καταστάσεις. ΔΕΝ είναι μηχανισμός ο οποίος θα χειριστεί τις καταστάσεις. Αυτό είναι δουλειά του προγραμματιστή, να σχεδιάσει τον κώδικα του έτσι ώστε να αντιμετωπίσει σωστά αυτή την έκτακτη κατάσταση. Το παράδειγμα με το ρελαί δεν είναι τυχαίο.

Είναι άλλο θέμα πως θα φτιάξεις κώδικα που αντέχει σε exceptions και άλλο πως θα χειριστείς τα exceptions ή τα errors:

Αντοχή (ή exception safety) σημαίνει ότι ο κώδικας θα δουλέψει σωστά ακόμα και αν υπάρξει exception και δεν θα αφήσει πράγματα στον αέρα. Κώδικας ο οποίος πειράζει global/external variables για παράδειγμα, δεν αντέχει τόσο όσο κώδικας ο οποίος τροποποιεί μόνο local coipes των variables και τα επιστρέφει. Ένα function που κάνει 5 διαφορετικά πράγματα είναι πιο επικίνδυνο από 5 μικρότερα functions που κάνουν μόνο 1 πράγμα. Τα functions του C++ Standard Template Library είναι exception safe παρότι (ή επειδή) δεν χρησιμοποιούν try/catch ακριβώς επειδή έχουν σχεδιαστεί ώστε να είναι exception safe.
Ο χειρισμός έχει να κάνει με το τί κάνεις αφού "πέσει" η ασφάλεια και συνεφέρεις το πρόγραμμα. Τί κάνεις, συνεχίζεις με το επόμενο βήμα, ακολουθείς άλλη διαδρομή, δοκιμάζεις ξανά? Στην πραγματικότητα μιλάμε για κώδικα ο οποίος δεν έχει σχέση (ή θέση) με το catch, αλλά εκτελείται αφού ολοκληρωθεί το catch και διαπιστωθεί ότι η εκτέλεση θα πρέπει να συνεχίσει με διαφορετικό τρόπο.

Και τα δύο θέματα απαιτούν προσεκτική σχεδίαση τόσο σε επίπεδο μεμονωμένων function όσο και στη σχεδίαση ολόκληρων modules.

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

Απ: C# ή VB.NET ?

Παναγιώτης Καναβός — Thu, 06 Dec 2012 21:31:10 GMT

BruteForce:

Τα συγκεκριμένα components εμπλεκόντουσαν στην αποστολή εντολών στο ΧΑΑ... μάλλον δεν υπερέβαλα. Και τόσα χρόνια ΠΟΤΕ δεν υπήρξε bug στις live εγκαταστάσεις.

Συνεπώς: ΔΕΝ φταίει η γλώσσα. ΦΤΑΕΙ ο προγραμματιστής.

Και μόλις θυμήθηκα την Knight Capital και το algorithmic trading. Όπως ίσως έχει διαπιστώσει και ο Δημήτρης, ο κόσμος που ασχολείται με χρηματιστηριακά δεν παίρνει και τόσο στα σοβαρά την ποιότητα και το error/exception safety του κώδικα. Υπάρχει ΠΟΛΥ On Error Resume Next ή catch {} στα χρηματιστηριακά. Σου λέει ο άλλος, αν βγει 1 μέρα νωρίτερα, θα βγάλω 1Μ παραπάνω και αν έχει προβληματάκια, ε θα τα συγυρίσω. Άσχετα αν η κακή σχεδίαση παράγει 1Μ προβλήματα.

Και βγαίνει που λες η Knight Capital με νέα υπηρεσία για algorithmic trading τον Αύγουστο, διαφημίζοντας ότι ήταν η πρώτη που έβγαλε υποστήριξη για τη ΧΨΩ πλατφόρμα, πρίν απ' όλους και τα σχετικά, πρώτη στην αγορά και όλα αυτά. Προφανώς, με το να βγούνε πρώτοι θα κερδίζανε κάμποσα μύρια σε σχέση με όσους θα έρχονταν μετά, οπότε κόψανε πάλι δρόμο. Αποτέλεσμα ....

Μέσα σε 45 λεπτά χάσανε $450 εκατομμύρια . Κάποιος "ξεχασμένος" κώδικας έσκασε, και οι εφαρμογές πουλούσανε φθηνά και αγοράζανε ακριβά λόγω λαθών. Η εταιρεία αναγκάστηκε να πουληθεί ουσιαστικά μέσα σε 4 μέρες.

Πάω στοίχημα πάντως ότι ο κώδικας ήταν γραμμένος σε C και έτρεχε σε Linux για να είναι πιο γρήγορος. Όπως όμως λέει και ο Δημήτρης, είναι ο προγραμματιστής, όχι η γλώσσα που μετράει.

Απ: C# ή VB.NET ?

BruteForce — Thu, 06 Dec 2012 21:03:53 GMT

Συμφωνώ με τα τελευταία σχόλια του Παναγιώτη.

Πριν από 2 χρόνια είχα μια μακροσκελή κουβέντα με τον Σπινέλλη.

Το θέμα μας ήταν το "ποιό ποσοστό του κώδικα είναι error handling" και αν μπορούν να φτιαχτούν εργαλεία metrics που να το μετράνε.

Η δική του εκτίμηση ήταν ότι για business critical συστήματα ήταν minimum 30%, και για mission critical (λειτουργικά, κλπ) περίπου 40%.

Εγώ, με βάση την προσωπική μου εμπειρία, δηλαδή το πώς γράφω κώδικα και πώς βάζω άλλους να γράφουν κώδικα, ήταν 40% και 50% αντίστοιχα.

Είναι εξαιρετικά εύκολο να γράψει κάποιος κώδικα που να δουλεύει σωστά, όταν ΟΛΑ πάνε καλά.

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

Για εμάς που είμαστε "παλιοί" τα exceptions είναι πολύ απλή ιστορία.

Υπήρχαν από την εποχή του DOS και Windows 3.1. Απλά setjmp και longjump και ήσουν έτοιμος.

Η χρήση τους υπερσπάνια, όπως π.χ. σε compiler γραμμένο σε C++ που κάνει την λεγόμενη αναδρομική κατάβαση.

Βέβαια δεν έκανε stack cleanup, έπρεπε να φροντίζω να κρατάω όλα τα objects κάπου, ώστε αν σκάσει "exception" να κάνω cleanup μόνος μου.

Σιγά το πράγμα.

Μετά τα NT βάλανε το SEH (Structured Exception Handling), το οποίο ήταν σε επίπεδο λειτουργικού, μαζί με finally, και δούλευε και σε kernel mode.

Πάλι, δεν είχε object cleanup. No big deal. Υπάρχουν εκατομμύρια γραμμες κώδικα που δεν χρησιμοποιούν objects.

Μετά τα έβαλε και η C++, ώστε κατά το stack unwinding να γίνονται cleanup τα local object (on stack), και μάλιστα επιτρέπει και μίξη SEH και C++ exceptions.

Πρέπει να καταλάβετε κάτι βασικό. Τα exceptions δεν είναι τίποτα άλλο παρά ένα φρικαλέο GOTO, που διατρέχει δεκάδες functions, με πιθανώς άγνωστο προορισμό, μαζί με ολίγη από gabrage colletion.

Είχε γράψει ο Joel Spolsky παλιότερα πάνω στο θέμα, ότι μισεί τα exceptions, και κάπου είχα γράψει και εγώ ότι τα υπερμισώ.

Ο λόγος;;;;

H σωστή κατανόηση και σωστή χρήση των exceptions είναι κάτι που ΔΕΝ μπορεί να συλλάβει ο μέσος προγραμματιστής.

Απλά ΔΕΝ ΜΠΟΡΕΙ.

Εγώ ξέρω πώς να τα χρησιμοποιήσω σωστά, αλλά γράφω κώδικα 20 χρόνια, έχω γράψει άπειρο mission critical kernel mode κώδικα, άπειρο business critical C++ κώδικα και κατανοώ πώς πρέπει να χειριζόμαστε τα exceptions και τι πάει να πει error handling.

Ο μέσος προγραμματιστής απλά θα κάνει ένα exception spaghetti.

Για να το θέσω απλά: Exception και Error ΔΕΝ ΕΙΝΑΙ ΤΟ ΙΔΙΟ ΠΡΑΓΜΑ.

Το .ΝΕΤ και η Java δυστυχώς το έχουν κάνει να φαίνεται το ίδιο, αλλά ΔΕΝ είναι το ίδιο.

Exceptions are exceptional or unpredictable problems, errors are expected or predictable problems.

Τα errors μπορούν να γίνουν handle, τα πραγματικά exceptions σπανίως.

Δοκιμάζει το πρόγραμμά σου να κάνει login κάπου (μέχρι χτες έπαιζε) και σήμερα παίρνει authentication error.

Αυτό είναι error, δεν είναι exception. Εϊναι 100% προβλέψιμο ότι θα συμβεί.

Πας να διαβάσεις ένα αρχείο, και δεν έχεις access στο directory.

Ή φορτώνεις και πας να σώσεις ένα αρχείο και κάποιος το έχει κάνει read-only. Έχεις security permissions, αλλά το αρχείο είναι read-only.

Γράφεις/Διαβάζεις από ένα USB Stick και ο χρήστης το βγάζει και την κάνει για Μπαχάμες.

Είναι errors όχι exceptions. 100% προβλέψιμο ότι θα συμβούν.

Κάνει ο κώδικάς σου download και κόβεται το connection. Error, not exception.

Τι είναι exceptions;

Κάνεις ένα query στη βάση, άμεσα ή έμμεσα, και τρώει timeout ή connection lost (στο local lan).

Κάνεις insert/update στη βάση και τρώει ο DB Server ένα disk full.

Πας να επικοινωνήσεις με έναν host και τρώς host unreachable.

Τρώς memory access violation exception (SEH) γιατί πήγες στα χωράφια.

Τρως memory allocation failure (memory full). To handling του memory full έχει πολύ πλάκα, έχω ρίξει απίστευτα γέλια. Τι μπορεί να κάνει ένα πρόγραμμα όταν τα Windows δεν μπορούν ούτε καν να ανοίξουν ένα message box???

Δηλαδή, νομίζετε ότι τόσα χρόνια τα λειτουργικά (στο μεγαλύτερο ποσοστό του κώδικα) και οι device drivers γράφονται σε C μόνο και μόνο για το performance;;; Και η C++ έχει ουσιαστικά το ίδιο performance.

Στα Windows όμως απαγορεύεται η C++ σε kernel code. ΑΠΑΓΟΡΕΥΕΤΑΙ. Γιατί;

(1) Έναν σοβαρό προγραμματιστή η C τον εξαναγκάζει να κάνει σωστό και πλήρες error handling. Και τον διευκολύνει να γράψει κώδικα δομημένο σωστά, γιατί ΔΕΝ του δίνει την επικύνδινη δυνατότητα για φρικαλέα GOTO.

(2) Ο κώδικας C είναι 100% predictable ώς προς το control flow. Δεν υπάρχουν "κρυμμένοι" copy constructors, destructors, garbage collections, overloaded operators κλπ που κάνουν μαγικά πράγματα χωρίς να παίρνει χαμπάρι τίποτα ο προγραμματιστής. Το control flow στη C είναι 100% explicit.

Ας το αφήσουμε αυτό, όποιος διαφωνεί δικαιωμά του.

Στην επιλογή γλώσσας προγραμματισμού και πλατφόρμας επικρατεί φυσική επιλογή.

Όσοι γουστάρουν και κατανοούν τα πολύπλοκα, κατανοούν και γουστάρουν το error handling και το επαγγελματικό error reporting, είναι οργανομένοι και τακτοποιημένοι μέσα στο μυαλό τους, δεν έχουν κανένα πρόβλημα με τη C και τη C++. Και καταλήγουν στις αντίστοιχες δουλειές.

Κάποιος που είναι ΟΚ με τη C++, την VB.NET θα την βρει μάλλον αηδιαστική, γιατί είναι πολύ πιο χύμα.

Εγώ την βρίσκω αηδιαστική και για τον επιπλέον λόγο, ότι εξαιτίας της φυσικής επιλογής, αν κουμάνταρα ένα project VB.NET τότε ΜΑΛΛΟΝ θα περιστοιχιζόμουνα από μέτριους και χύμα προγραμματιστές. Απλό είναι. Εγώ αν έγραφα VB.NET ο κώδικάς μου θα ήταν ολόιδιος με τη C#. 40-50% error handling. Και θα δούλευαν όλα ρολόι. Αλλά οι άλλοι γύρω μου;;;

Συνεπώς, αν δεχτείτε την εκτίμηση του Σπινέλλη για 30-40% error handling code, και κοιτάξετε ξανά τον κώδικά σας, θα δείτε ότι ΔΕΝ φταίει η γλώσσα. Οι προγραμματιστές φταίνε. Αυτά τα παραμύθια ότι η γλώσσα σε προστατεύει από λάθη, είναι 90% ΜΥΘΟΣ.

Δηλαδή το πρόβλημα της C/C++ είναι ότι δεν σε προστατεύει επειδή δεν ελέγχει τα array bounds???

Εϊπαμε, φυσική επιλογή. Αν δεν μπορείς να γράψεις κώδικα που χειρίζεται ένα φουκαριάρικο array σωστά, τότε ΠΑΡΑΤΑ τη C/C++, δεν είναι για σένα, δεν κάνεις για τις δουλειές που απαιτούν C++.

Ή το πρόβλημα είναι τα memory leaks? Αν δεν μπορείς να χειριστείς σωστά το memory handling, τότε ΠΑΡΑΤΑ τη C/C++, δεν κάνεις για τις δουλειές που απαιτούν C++.

Και το .ΝΕΤ έχει memory leaks, κάντε ένα google search να ρίξετε γέλιο. Ο Μανωλιός έβαλε τη σκούφια του αλλιώς.

Έχω γράψει και εγώ μπόλικη VB6 στο παρελθόν. Και είχα γράψει και OnError Resume Next. Αλλά έλεγχα το τιμημένο error code, δεν συνέχιζα στην καλή χαρά.

Αν έβλεπες την VB6 που έγραφα θα φρικάριζες, ήταν τόσοι πολλοί οι έλεγχοι που γινόντουσαν και τόσο αναλυτικό το error reporting που όντως ήταν το 30-40% του κώδικα. Και όταν τον βλέπανε οι normal VB6 programmers της εταιρίας, πραγματικά "φρικάρανε" και με ρωτάγανε αν πράγματι χρειάζεται τόσο πολύ error checking και μήπως υπερβάλλω.

Τα συγκεκριμένα components εμπλεκόντουσαν στην αποστολή εντολών στο ΧΑΑ... μάλλον δεν υπερέβαλα. Και τόσα χρόνια ΠΟΤΕ δεν υπήρξε bug στις live εγκαταστάσεις.

Συνεπώς: ΔΕΝ φταίει η γλώσσα. ΦΤΑΕΙ ο προγραμματιστής.

End of Story

Απ: C# ή VB.NET ?

Παναγιώτης Καναβός — Thu, 06 Dec 2012 19:40:46 GMT

Ούτε προφήτης να ήτανε ... Ο Διομήδης Σπινέλλης ανέβασε blog post για το πόσο επηρεάζονται διάφορες γλώσσες από τυχαία λάθη και κυρίως, κατά πόσο λανθασμένος κώδικας μπορεί να οδηγήσει σε λανθασμένα αποτελέσματα.

Η VB δεν περιλαμβάνεται στις 10 γλώσσες λόγω ... περιορισμένης δραστηριότητας (στο IOBE, το Craigslist και σε διαθέσιμο source) αλλά η παρομοίως ανεκτική PHP βγήκε η χειρότερη γλώσσα, με ~35% των λαθών να οδηγούν σε λανθασμένα αποτελέσματα αντί για κάποιο σκάσιμο.

Αντιθέτως, οι ασφαλέστερες ήταν οι γλώσσες της οικογένειας C/C++/C#/Java, με τη σειρά ... C++, C#, C και Java με ποσοστά 9-10%.

Η πλήρης δημοσίευση με νούμερα είναι εδώ

Απ: C# ή VB.NET ?

Παναγιώτης Καναβός — Thu, 06 Dec 2012 18:58:17 GMT

To On Error Resume Next είναι αντίστοιχο με το να τυλίγεις μία καμένη ασφάλεια με αλουμινόχαρτο - ή να κολλάς επάνω το ρελαί που έπεσε. Τα exceptions είναι ο τρόπος της γλώσσας και του λειτουργικού να σου πουν ότι κάτι σοβαρό συνέβει και κάηκε η ασφάλεια.

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

Όσο για το "γιατί να παιδευτώ", ένα από τα χαρακτηριστικά που ξεχωρίζει τους junior από τους senior developers ή αυτούς που ασχολούνται επαγγελματικά με τον προγραμματισμό από αυτούς που προγραμματίζουν περιστασιακά, είναι ακριβώς ο βαθμός στον οποίο θέλουν να κάνουν κάτι σωστά αντί να το κάνουν "στα γρήγορα".

Τέτοια "στα γρήγορα" έχουν οδηγήσει σε τραγελαφικές καταστάσεις, όπως τη φορά που βρήκα κώδικα που γύριζε υπόλοιπο λογαριασμού 0 σε χρηματιστηριακή γιατί ... μάντεψε .... κάποιος είχε βάλει On Error Resume Next στο σημείο που διάβαζε την ισοτιμία του δολλαρίου. Ένα σκασιματάκι που έκανε Resume Next και όλοι οι λογαριασμοί βγήκαν 0.

Απ: C# ή VB.NET ?

Tsopi — Thu, 06 Dec 2012 00:45:23 GMT

Παρόλο που συμφωνώ μαζί σου για την On Error GoTo/Resume Next, πραγματικά πιστεύω πως έχει λάβει υπερβολικά αρνητική κριτική και δεν της αξίζει γιατί υπάρχουν κάποιες περιπτώσεις που έχεις μια function που κάνει κάποια δουλειά κατά την οποία αν προκύψει πρόβλημα , να θες να το αγνοήσεις.

Γιατί πρέπει οπωσδήποτε δηλαδή να βάλεις Try Catch σε ένα μεγάλο μέρος της συνάρτησης και να μην βάλεις ένα On Error Resume Next στην αρχή ( αυξάνοντας και την ευκολία στο debuging γιατί όποτε δεν το θές , κάνεις comment out την πρώτη γραμμή και δεν ψάχνεις να βρεις το Try, to Catch και το End Try).

Επίσης, ακόμα και μια λούπα μπορεί να θες να την αγνοήσεις. Θυμάμαι που έφτιαχνα ένα μικρό σύστημα εντοπισμού τραγουδιών μέσα στα αρχεία ενός User και καθώς έψαχνα τους φακέλους, κάποιοι δεν έδιναν στην εφαρμογή το δικαίωμα να τους ψάξει, και σταματούσε την εφαρμογή για έναν τελείως ασήμαντο λόγο. Οκ, δεν με νοιάζει να ψάξω φακέλους του συστήματος για να βρώ τα τραγούδια μου! Γιατί να παιδευτώ και να βάλω try?

'QUICK SEARCH
            If My.Settings.QuickSearch Then
                On Error Resume Next
                For Each Dir As String In My.Computer.FileSystem.GetDirectories("C:\Users\" & UserName(), FileIO.SearchOption.SearchTopLevelOnly)
                    If Not Dir.Contains("AppData") Then TopLevel.Add(Dir)
                Next
            Else
                TopLevel.Add("C:\")
            End If

Στα υπόλοιπα συμφωνώ :)