Error handling

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

In Try-Catch we can trap the error in run-time with err.number or err.description
But some errors like "File not exist", "Device not ready", ect... are taken over by the system before come into Try-Catch

I have a code like this
-----------
1. If OpenFileDialog1.ShowDialog() = DialogResult.Cancel The
2. Exit Su
3. End I
4
5. If OpenFileDialog1.FileName <> "" The
6. Tr
7. FileOpen(1, OpenFileDialog1.FileName, OpenMode.Input
8. Catc
9. MsgBox(Err.Number & " - " & Err.Description
10. End Tr
11. End I
---------
When the OpenFileDialog windows appeared, I inputed a filename that doesn't exist
The message windows from the system appeared directly
" (file name).......... does not exist
Please verify that the correct file name was given.
This message appear before the process come into Try-Catch. I know it because I put a break point at line 1

I know that I have to set something somewhere in Debug Menu
But I don't know How and Where

Can somebody tell me how to do it ? Please

Regards
Joachi
 
It sounds like you're simply running into an issue with the OpenFileDialog.
There is a member variable called "CheckFileExists" that is set to "True" by
default. Therefore, if you enter a file name that does not exist the
OpenFileDialog will prompt you to enter a valid file name before continuing.

If you wish to use your own error handling code to check for valid file
names then simply set this variable to "False" before showing the dialog. Of
course, it's much easier to let the OpenFileDialog check for valid file
names and paths rather than doing this yourself. You can simply assume that
the file exists as long as the dialog returns a value of DialogResult.OK.

Scott


Joachim said:
Hi,

In Try-Catch we can trap the error in run-time with err.number or err.description.
But some errors like "File not exist", "Device not ready", ect... are
Click to expand...
taken over by the system before come into Try-Catch.
I have a code like this :
------------
1. If OpenFileDialog1.ShowDialog() = DialogResult.Cancel Then
2. Exit Sub
3. End If
4.
5. If OpenFileDialog1.FileName <> "" Then
6. Try
7. FileOpen(1, OpenFileDialog1.FileName, OpenMode.Input)
8. Catch
9. MsgBox(Err.Number & " - " & Err.Description)
10. End Try
11. End If
----------
When the OpenFileDialog windows appeared, I inputed a filename that doesn't exist.
The message windows from the system appeared directly.
" (file name).......... does not exist.
Please verify that the correct file name was given."
This message appear before the process come into Try-Catch. I know it
Click to expand...
because I put a break point at line 1.
 
Although Scott has given you some pointers to resolve your issue, I would suggest putting all your code within the Try..Catch loop so that any errors are caught by your own error handling and not the .NET runtime which is messy and not very friendly for an end-user. I generally wrap all the code in each of my procedures in a Try..Catch loop (as a catch-all) and if I then need to then trap specific errors within the procedure code I create nested Try..Catch loops around the appropriate code

Gary
 
Hi Gary,

A try and catch is in my opinion to catch errors that you can not resolve in
design time, it is not a method to help you with bad programming.

I think this is not a good advice for the OP.

Cor
 
Hi Cor

I afraid I will have to disagree with you on this one. Yes, in a perfect world every single line of the code would be properly tested for every concievable scenario and would be completely bug-free before it gets anywhere near an end user but in today's world with tight deadlines and quality being sacrificed for profit, that rarely happens even with the most stringent of testing methods

With the complex logic in a lot of today's applications, testing every single route through the code in conjunction with every single scenario that may occur is next to impossible, even with years of testing

Putting a Try..Catch around the whole procedure as a catch-all (in addition to any individual errors you wish to handle separately) simply ensures that an end user is NEVER subjected to the .NET runtime error dialog due to something that managed to slip through the net during the development and testing phases. I have tried various methods of error handling and this has turned out to be the best and most successful way of implementing it

We employ this mechanism our apps and it works exremely well and helps us provide a good level of customer service. Our error handling mechanism enhances the existing .NET stack tracing and in the event of an error (unexpected or not) we log all details that enables us to very quickly pinpoint and fix the issue. In the event of an error, the user is presented with a 'friendly' error message (well, as friendly as you can get for an error message!) and the app then attempts to automatically recover to an a state where the user can carry on

That said, it would be interesting to hear other people's views on doing this and/or how they implement error handling in their own .NET applications

Gary
 
Hi Gary,

Thanks for your message, there is sense in it, but I keep it with my
opinion. As you said, let us wait if others give comments.

(I said yesterday to Tom Leyton, that I like solutions, and not bandages, I
think this is the same)

Understand me well; it is a way to go. However, not one I would recommend at
the start.

Cor
 
Thanks for your suggestions and opinions
But I still think that we can set somethings in Debug/Exception menu. So we can take the Error-Handling over from system and let the program trap and handle the errors in the design fase
This is not just for OpenFileDialog but also for another. example : Print, ect
 
Well, the way I see error handling depends on the situation where you're
using it. For things such as the common dialog issue discussed in this post
I wouldn't bother checking to make sure that a file name was entered or that
it actually existed since the OpenFileDialog will do this for you. I have
used this a great deal and have never had a problem with something slipping
through the cracks. It doesn't present a message saying that your
application has failed to work properly. It simply states that the file
doesn't exist and asks the user to verify the file name. Therefore, it
simply keeps me from having to implement one more Try/Catch handler.

However, I do believe in using Try/Catch statements whenever there is a
possibility of an error popping up. Presenting an application-specific error
dialog shows the end user that there was at least some thought that went
into the process rather than just throwing the code together and crossing
your fingers. You can't predict all errors that will occur, but you can at
least trap them and allow the application to continue if possible.

So it basically comes down to the particular piece of code in question and
the developer's experience with it. Essentially, how confident are you that
the code will work? That's my opinion.... Of course everyone has an
opinion....

Scott
 
Back
Top