C# - Retrieving Error codes

[EFileTahi-A]

I want to get the numeric code for errors that are catch by "Try-Catch" keywords but I don't know how to do it...

 

I can get the error message description, no problem on that, but I need the code number too, like:

 

"Error 210: The file is write protected"

Edited October 4, 2005 by EFileTahi-A

[PlausiblyDamp]

Exceptions as a rule do not have associated error codes - the exception type denotes the error condition itself.

Certain exception derived classes may expose an error number that is specific to the exception type i.e. SQLException exposes the underlying SQL error number.

Is there a reason why you feel you need to associate a number with a particular error?

[EFileTahi-A]

Yes, I want to write my own error messages which would make more sense on my application, like, if I get an error saying something like: "ERROR: File name was not found." this is not informing what I REALLY want the user to understand, which is: "You have to save your project first in order to continue."

 

I made this in VB6 easly because in VB6 each error had a numeric code. I could identify the error through it's number and show the correct customized error message this way (unlike .NET).

[PlausiblyDamp]

Are you wanting to identify what type of error occured and then display an appropriate error messge based on that or are you looking at generating your own error messages of the form:

"Error XXX: Some error occurred" - where XXX is a unique error number?

 

If the latter then you would just need to provide your own error numbers in the messages themselves.

If the former then your try catch would need to trap the correct exception types and act accordingly.

 

try {
//do something that could cause an error here
FileStream fs = new FileStream("c:\\test.txt");
}
catch (FileNotFoundException ex)
{
//handle file not found
}
catch(SecurityException ex)
{
//handle insufficient permissions here
}

[snarfblam]

Alternatively, you could have a cascading if/elseif/elseif checking the type of the exception, since, from the sounds of things, your exception handling behavior will not vary depending on the exception type.

//using the is operator
try 
{
   //Your code here
}
catch (System.Exception ex)
{
   if (ex is FileNotFoundException)
       MessageBox.Show("You must save your files before you can continue.");
   else if (ex is SecurityException)
       MessageBox.Show("You lack sufficient permissions to perform the specified action.");
   else
       MessageBox.Show("An unexpected error occured. (Don't you hate it when you get a message like this?");
}

Excuse me if my C# is less than perfect, I don't really program C#.

[EFileTahi-A]

Thank you both for your replies. I guess I can't get the error number codes huh? Anyway you mention some good walkrounds though. The whole ideia would be as Marble Eater mentioned, the error would be send to a class that would then follow from an "cascace ElseIf checks" or "Switch to" to the correct error.

 

I can numerate the errors alright, but, to do that I must identify them or separate them into types/categories. Now, how do I get the error type? Using Marble Eater's example "if (ex is FileNotFoundException)"?

 

Er... If so, where can I get a list of all exception types? I'll try to browse the web about this...

 

NOTE: This "missing file error" was just an example. I do want to rewrite ALL error messages to my native language...

Edited October 10, 2005 by EFileTahi-A

[PlausiblyDamp]

MSDN should have a full list of all the Exceptions thrown by .Net and the framework - see clicky for a starting point.

Then again you may be better of investigating the Exception Handling Application Block to see if it can prevent you re-inventing the wheel.

[IngisKahn]

I do want to rewrite ALL error messages to my native language...

Why?

http://www.microsoft.com/downloads/details.aspx?displaylang=pt-br&FamilyID=04DBAF2E-61ED-43F4-8D2A-CCB2BAB7B8EB

[EFileTahi-A]

IngisKahn, I know about the existence of language translations to .NET. But I want to translate the error messages my with own words and convert some of them to specific momments of my application... Edited October 10, 2005 by EFileTahi-A

[IngisKahn]

Then PD's example is the way to go. You can't really get a list of all the exception types, since anyone can inherit from Exception, but doing a search for Exception in Object Browser will get a list of all those that are defined.

[snarfblam]

Just a note: If, for example, you are trying to perform an action that requires a certain file to exist, you should check first to see is the file exists. You should generally try to avoid causing exceptions as much as possible. Try to use them to handle errors you don't see coming or can not prevent, not as a method to control program flow, because they are designed and intended to be used for "exceptional circumstances," which should be few and far between.

 

If your program is set up only to use exceptions as intended, then chances are that when they occur, the most useful information that you will be able to give a user is that an error occured, or maybe something like "A file access error has occured," because you will be preventing predictable exceptions and the exceptions caught will most likely do little to explain why exactly an operation failed, but instead offer you a chance to recover.

[EFileTahi-A]

Just a note: If, for example, you are trying to perform an action that requires a certain file to exist, you should check first to see is the file exists. You should generally try to avoid causing exceptions as much as possible. Try to use them to handle errors you don't see coming or can not prevent, not as a method to control program flow, because they are designed and intended to be used for "exceptional circumstances," which should be few and far between.

 

If your program is set up only to use exceptions as intended, then chances are that when they occur, the most useful information that you will be able to give a user is that an error occured, or maybe something like "A file access error has occured," because you will be preventing predictable exceptions and the exceptions caught will most likely do little to explain why exactly an operation failed, but instead offer you a chance to recover.

 

Yeah, I know what you mean, but that is another story. I mean, I display a special window which contains the original message along with the form name and function that triggered it, plus, a customized message, this last one is target for the comon user. Yet, A'm definetly NOT setting up the display messages based on exceptions... Only in few circustances.

 

Typicaly, when a error message pops up during runtime chances are you have a bug in your code, so, I rather fix it then protected it with a try-catch block... ;)

Edited October 11, 2005 by EFileTahi-A

[PlausiblyDamp]

Just a couple of points on exceptions in general...

 

Be aware that catching all Exceptions with code like

catch(Exception ex)

(well CLS compliant ones anyway) is potentially a bad thing - you are basically saying that whatever goes wrong you are happy to catch and correctly handle the resultant exception, regardless of what it is. Some exceptions are going to be well beyond your ability to deal with e.g. OutOfMemoryException, StackOverflowException and similar, if you must catch all exceptions then you also probably want to rethrow them rather than just swallowing them...

Also using a series of specific catch blocks, that target the exceptions you are expecting to deal with, rather than a single catch block with a nested if statement makes it much harder for exceptions to be accidently ignored during development only to surface in someway after deployment.

 

As a final note you also need to be aware of the relative performance aspects, although exceptions can be less efficient than checking in advance you need to weigh up a couple of things:

1) How often is the exception likely to occur? If you are checking for the presence of a file before opening it and you would expect the file to be present nearly all the time it may be simpler in the long run to assume it is present and handle the odd occasion when it isn't by catching the exception.

2) Code like

//May not compile, no VS on this pc but you should get the idea
if (System.IO.File.Exists("c:\\test.txt")
{
System.IO.FileStream = System.IO.File.Open("C:\\test.txt");
//use fs
}

introduces a race condition - there is always the possibility that the file could be present when the initial check is performed but deleted before the attempt to open it! You would still need to handle the possibility of an exception anyway...