Minor rant time:
< rant >
Every day I see questions on boards like:
"When I tried to run my app, I get an < error type here > error. Can you tell me what's wrong?"
To anyone who's done programming for any length of time, usually the only way to answer this question is with other questions:
What line of code caused the error?
Did you try stepping through the code to see what might have caused the error?
Why don't you have error handling code in your app?
I'm stumped as to why people believe we're mind readers and can answer their question without providing at least the information to answer the first question above. Also, based on the posts. I appears that the first time an error pops up in their app, they run to a message board and post the question without even trying to debug the problem. Probably 75-90% of the posts on boards could be eliminated by people spending 2 minutes in stepping through their code to debug the problems. I fear for the state of IS shops if the above is typical of the way soon-to-be programmers handle bugs in their apps. Are Comp Sci teachers not teaching their students how to handle errors or is it just laziness on the part of people (or worse, both!)?
I understand that there are times when your knowledge is not equal to the task of solving a problem. I've been there, believe me (and still am, as is probably everyone that tries to learn new technology). However, do yourself a favor and at least try to solve the problem before running to a message board for help. Not only will you probably solve the problem quicker than if you had waited for an answer to your post, but you'll probably also learn something in the process. Also, spend the extra couple of minutes to add error handling code to your app. Any code where an error could pop up should have code to handle the error(s). If you're using a language that allows you to trap for specific errors, do so. For instance, consider the following code:
Imports System
Imports System.IO
Public Class Test
Public Shared Sub Main()
Dim path As String = "c:\temp\MyTest.txt"
Dim fs As FileStream = New FileStream(path, FileMode.Open)
Dim sr As StreamReader = New StreamReader(fs)
Do While sr.Peek() >= 0
Console.WriteLine(sr.ReadLine())
Loop
sr.Close()
fs.Close()
End Sub
End Class
Doesn't seem like there's anything wrong, correct? Of the 8 lines of code that do something, at least 2 could cause exceptions:
Dim fs As FileStream = New FileStream(path, FileMode.Open)
Dim sr As StreamReader = New StreamReader(fs)
The assumptions here are that the file pointed to by "path" exists and the FileStream is actually created. To fix this you could take the easy route:
Imports System
Imports System.IO
Public Class Test
Public Shared Sub Main()
Dim path As String = "c:\temp\MyTest.txt"
Try
Dim fs As FileStream = New FileStream(path, FileMode.Open)
Dim sr As StreamReader = New StreamReader(fs)
Do While sr.Peek() >= 0
Console.WriteLine(sr.ReadLine())
Loop
sr.Close()
fs.Close()
Catch e As Exception
MessageBox.Show("The process failed: " & e.ToString())
End Try
End Sub
End Class
That would help, but there's more you could do:
Imports System
Imports System.IO
Public Class Test
Public Shared Sub Main()
Dim path As String = "c:\temp\MyTest.txt"
Try
If File.Exists(path) Then
Dim fs As FileStream = New FileStream(path, FileMode.Open)
Dim sr As StreamReader = New StreamReader(fs)
Do While sr.Peek() >= 0
Console.WriteLine(sr.ReadLine())
Loop
Else
MessageBox.Show("File doesn't exist")
End If
Catch eArgNullEx As ArgumentNullException
MessageBox.Show("Error opening file stream: " & eArgNullEx.Message & " - " & eArgNullEx.InnerException.Message)
Catch eArgEx As ArgumentException
MessageBox.Show("File cannot be read: " & eArgEx.Message & " - " & eArgEx.InnerException.Message)
Catch e As Exception
MessageBox.Show("The process failed: " & e.Message & " - " & e.InnerException.Message)
Finally
sr.Close()
fs.Close()
End Try
End Sub
End Class
Better. :) Always try to trap for specific errors by the most specific first and always have a Catch for the general Exception class. Try to give as much information on the error as possible. There's no such thing as overkill on providing info on errors, at least when you're debugging. A release version should probably give a user friendly message and allow the user to copy the more technical information to send to a
support person. Yes it means more code to write. There's add-ins out there that will drop skeleton Try...Catch code in for you (blatant plug for CodeSmart - http://www.axtools.com/). If you're working for a company that can, get them to buy it and use it. You'll thank yourself when some obscure error pops up and you don't have to go digging for information to help fix the problem.
< /rant >