The perils of stubbing out methods

Posted by dragon on Saturday, 24 September 2011

I only have a single-thread brain. Sad, but true. I can only really concentrate on one thing at a time.

For example, when I'm writing, I like to stub out sections of code so I can some back and flesh them out when I've finished something else. Take thei example of some code in process:

Public Function GetString(AllTheString as Boolean) as String
    If AllTheString Then
        Return "You asked for all the string"
    Else
        'Add the 'Not-All-The-String' in a minute.
        'Why not make a coffee?
    End If

You get the point. I can deal with the other path the code can take at some point in time. Perhaps after a coffee. However, this approach doesn't work in SQL Server 2000. I'm sure it's well documented and whatnot, but it really did give me some grief earlier today. Take this example:

CREATE PROCEDURE ThisIsATest
    (@TestValue int)
AS

IF EXISTS(SELECT TheKey FROM TheTable WHERE TheKey = @TestValue
BEGIN
    INSERT INTO AuditTable(Event, Time)
    VALUES ('This value was found: ' + @TestValue, GETDATE())
END
ELSE
BEGIN
    /*I'll worry about this part in a minute
    I quite feel like a coffee roundabout now...*/
END

Hit the 'Validate SQL' button, and it'll return an error. A nice error? A helpful error? An error that might vaguely suggest that you might have a code path that doesn't actually so anything? No. What does it come back with?

Incorrect syntax near the keyword 'END'

Pointing at the last line of the script.

Took me ages of sifting through a long SPROC before I realised that was what it was trying to tell me. Bugger. All I was trying to dso was vlidate the SQL I had writen so I could move on to the other part.

Just wanted to share. Apologies for irrelevance and brevity, but it's late. All because of this very thing!

{ 0 comments... read them below or add one }

Post a Comment