What is the difference between code like this:
string path = #"c:\users\public\test.txt";
System.IO.StreamReader file = new System.IO.StreamReader(path);
char[] buffer = new char[10];
try
{
file.ReadBlock(buffer, index, buffer.Length);
}
catch (System.IO.IOException e)
{
Console.WriteLine("Error reading from {0}. Message = {1}", path, e.Message);
}
finally
{
if (file != null)
{
file.Close();
}
}
and this:
string path = #"c:\users\public\test.txt";
System.IO.StreamReader file = new System.IO.StreamReader(path);
char[] buffer = new char[10];
try
{
file.ReadBlock(buffer, index, buffer.Length);
}
catch (System.IO.IOException e)
{
Console.WriteLine("Error reading from {0}. Message = {1}", path, e.Message);
}
if (file != null)
{
file.Close();
}
Is really finally block necessary in this construction. Why Microsoft provided such construction? It seems to be redundant. Isn't it?
Imagine if some other exception occurred that you haven't handled, e.g. an ArgumentOutOfRangeException, or if you want to rethrow the exception or throw a wrapped exception from your catch block:
The first block would ensure that the file is closed regardless of whether or not an exception occurred.
The second block would only close the file if either no exception occurred or an IOException occurred. It does not handle any other cases.
The first block will close the file even if there is an uncaught exception.
The second block will close the file only if there are no exceptions, or any thrown exceptions are caught.
The first will also ensure that the file is closed if the try has a break, goto, return, continue, or any other jump construct that would cause the execution to move outside of the try block. The second doesn't, and as such it could result in the resource not being closed.
In your example, if your code throws an exception other than System.IO.IOException, your cleanup code is not guaranteed to run. With the finally block, the code within it will run no matter what type of exception is thrown.
In that case it's redundant.
It's usefull if you for example will rethrow an exception and still want some code to run after the block:
try {
// do something dangerous
} catch(...) {
// log the error or something
throw; // let the exception bubble up to the caller
} finally {
// this always runs
}
// this only runs if there was no exception
Another example is if the catch may throw an exception for a different reason:
try {
// do something dangerous
} catch(...) {
// handle the error
// log the error, which may cause a different exception
} finally {
// this runs even if the catch crashed
}
// this only runs if there was no exception, or the code in the catch worked
Simply, as code might crash for plenty of reasons you might not even know about, it's useful to put the cleanup in a finally block just to be sure that it runs whatever happens.
Imagine there was an exception inside catch{}, code inside finally would still run but if (file != null){} block will not.
Related
I have a socket and I'd like to send messages and read from it.
When I read/write with the socket while the other side is offline, I get the same Exception: System.IO.IOException: Unable to read data from the transport connection: Operation on non-blocking socket would block.
How can I identify in which of the two it happened besides having two separate try-catch blocks? Can't I just get a Timeout Exception when the reading timeout is over?
example:
try
{
SendData("!GetLocation!");
string data = GetData();
}
catch (Exception ex)
{
if (ex is System.IO.IOException)
{
//How can I identify if the exception was raised at the read method or the write method?
}
}
Yeah, exception handling is heavy resource wise, but sometimes is not so bad.
If you stick to only one try-catch you can check the error message.
Note: I have also added a second try-catch for generic (non IO) errors
try
{
SendData("!GetLocation!");
string data = GetData();
}
catch (System.IO.IOException ex)
{
if (ex.Message.IndexOf("Unable to read") != -1)
{
// GetData error
}
else if (ex.Message.IndexOf("Unable to write") != -1)
{
// SendData error
}
else
{
//Other IO errors
}
}
catch(Exception exc)
{
// Unspected errors
}
you could also set a boolean variable and check its value to know where it
broke your code.
bool sendCalled = false;
try
{
SendData("!GetLocation!");
sendCalled = true;
string data = GetData();
}
catch (System.IO.IOException ex)
{
if (sendCalled)
{
// GetData error
}
else
{
// SendData error
}
}
Not that I endorse either of these solutions, but an answer is an answer: you can either
analyze the stack trace of the exception to find out which call failed (e.g. name of the method at the top of the stack frame
set a flag after the write, and do logic based on that flag
Neither of these is as straight forward as wrapping each method call. In fact, wrapping each call conveys your intent. In the catch of your first call, you can return/break/skip the read call, which explicitly tells the reader you're bailing out fast.
I am writing a C# application in which I have to display a message if File is already being used by some process and if the file doesnot exist, the application needs to display another message.
Something like this:
try
{
//Code to open a file
}
catch (Exception e)
{
if (e IS IOException)
{
//if File is being used by another process
MessageBox.Show("Another user is already using this file.");
//if File doesnot exist
MessageBox.Show("Documents older than 90 days are not allowed.");
}
}
Since IOException covers both the conditions, how do I distinguish if this exception is caught because of File being used by another process or File doesnot exist?
Any help would be highly appreciated.
Always catch from the most specific to the most generic exception type.
Every exception inherits the Exception-class, thus you will catch any exception in your catch (Exception) statement.
This will filter IOExceptions and every else separately:
catch (IOException ioEx)
{
HandleIOException(ioEx);
}
catch (Exception ex)
{
HandleGenericException(ex);
}
So catch Exception always last. Checking with if is possible, but not common.
About your problem:
if (File.Exists(filePath)) // File still exists, so obviously blocked by another process
This would be the simplest solution to separate your conditions.
As you can see here File.OpenRead can throw these exception type
ArgumentException
ArgumentNullException
PathTooLongException
DirectoryNotFoundException
UnauthorizedAccessException
FileNotFoundException
NotSupportedException
for each of this exception type you can handle it in this way
try{
}
catch(ArgumentException e){
MessageBox.Show("ArgumentException ");
}
catch(ArgumentNullExceptione e){
MessageBox.Show("ArgumentNullExceptione");
}
.
.
.
.
catch(Exceptione e){
MessageBox.Show("Generic");
}
In your case you can handle just one or two types and other are always catched by generic Exception (it must be always the lastone because cathces all Exceptions)
Try the following:
try
{
//open file
}
catch (FileNotFoundException)
{
MessageBox.Show("Documents older than 90 days are not allowed.");
}
catch (IOException)
{
MessageBox.Show("Another user is already using this file.");
}
More info: http://www.dotnetperls.com/ioexception
I know this is old, but the only consistent solution to do this is to filter catch blocks by the HResult property. I don't know which one it is but here's an example for copying a file and catching if the file already exists :
try
{
File.Copy(source, dest, false); // Try to copy the file normally
}
catch (IOException e) when (e.HResult == -2147024816) // 0x80070050 : The file already exists
{
// Prompt user for overwrite...
}
Consult the .NET reference source and track the Win32 calls to find the returned HResult.
When file not exists it will throw the FileNotFoundException that inherit IOException, So you can write like this:
try
{
//file operate
}
catch (FileNotFoundException ex)
{
MessageBox.Show("Documents older than 90 days are not allowed.");
}
catch (IOException ex)
{
MessageBox.Show("Another user is already using this file.");
}
I have to process items off a queue.
Deleting items off the queue is a manual call to Queue.DeleteMessage. This needs to occurs regardless of whether or not the processing succeeds.
var queueMessage = Queue.GetMessage();
try
{
pipeline.Process(queueMessage);
}
catch (Exception ex)
{
try
{
Logger.LogException(ex);
}
catch { }
}
finally
{
Queue.DeleteMessage(queueMessage);
}
Problem:
On failure, I log the error to some data store. If this logging fails (perhaps the data store is not available), I still need the message to be deleted from the queue.
I have wrapped the LogException call in another try catch. Is this the correct way or performing thing?
Following code is enough. finally blocks execute even when exception is thrown in catch block.
var queueMessage = Queue.GetMessage();
try
{
pipeline.Process(queueMessage);
}
catch (Exception ex)
{
Logger.LogException(ex);
}
finally
{
Queue.DeleteMessage(queueMessage);//Will be executed for sure*
}
The finally block always executes, even if it throws an unhandled error (unless it end the app). So yes.
Is there a way to handle the error "WebDev.WebServer.Exe has stopped working" in ASP.NET and keep the page running or even the just the WebServer running? Or is this an impossible task and is essentially like asking how to save someone's life after they've died?
I have the error-causing code inside a try/catch block, but that doesn't make a difference. I've also tried registering a new UnhandledExceptionEventHandler, but that didn't work either. My code is below in case I'm doing something wrong.
Also to be clear, I'm not asking for help on how to prevent the error; I want to know if and when the error happens if there's anything I can do to handle it.
UPDATE 1: TestOcx is a VB6 OCX that passes a reference of a string to a DLL written in Clarion.
UPDATE 2: As per #JDennis's answer, I should clarify that the catch(Exception ex) block is not being entered either. If I removed the call to the OCX from the try\catch block it still won't reach the UnhandledException method. There are essentially two areas that don't ever get executed.
UPDATE 3: From #AndrewLewis, I tried to also add a regular catch block to catch any non-CLS compliant exceptions, and this did not work either. However, I later found that since .NET 2.0 on, all non-CLS exceptions are wrapped inside RuntimeWrappedException so a catch (Exception) will catch non-CLS compliant exceptions too. Check out this other question here for more info.
public bool TestMethod()
{
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
string input = "test";
string result = "";
try
{
TestOcx myCom = new TestOcx();
result = myCom.PassString(ref input); // <== MAJOR ERROR!
// do stuff with result...
return true;
}
catch (Exception ex)
{
log.Add("Exception: " + ex.Message); // THIS NEVER GETS CALLED
return false;
}
}
private static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
// THIS NEVER GETS CALLED
try
{
Exception ex = (Exception)e.ExceptionObject;
log.Add("Exception: " + ex.Message);
}
catch (Exception exc)
{
log.Add("Fatal Non-UI Error: " + exc.Message);
}
}
You should try catching non-CLS compliant exceptions to make sure nothing is being thrown (keep in mind you don't want to do this in production, always be specific!):
try
{
TestOcx myCom = new TestOcx();
result = myCom.PassString(ref input); // <== MAJOR ERROR!
// do stuff with result...
return true;
}
catch (Exception ex)
{
log.Add("Exception: " + ex.Message); // THIS NEVER GETS CALLED
return false;
}
catch
{
//do something here
}
Your code reads //THIS NEVER GETS CALLED.
If you catch the exception it is no longer un-handled. this is why it doesn't fire an unhandledexception event.
I'm using TweetSharp to find the followers for a user.
Here is the code:
public static void FindFollowersForUser(TwitterUserModel twitterUser)
{
try
{
var followers = service.ListFollowersOf(twitterUser.TwitterName, -1);
if (followers == null) return;
while (followers.NextCursor != null)
{
var foundFollowers = service.ListFollowersOf(twitterUser.TwitterName, (long)followers.NextCursor);
if (foundFollowers == null) continue;
Debug.WriteLine("Followers found for: " + twitterUser.TwitterName);
foreach (var follower in foundFollowers)
{
twitterUser.Followers.Add(follower.ScreenName);
}
}
}
catch (WebException e)
{
throw e;
}
}
I've tried wrapping the code in a try/catch, to catch the WebException error being fired and review it's InnerException, but the catch is never entered despite the error message being shown in the output window (View -> Output) in Visual Studio.
How can I see the inner exception of this breaking bug? This is the first time I've seen the debugger not firing the catch when an exception is fired.
I assume when you say "First chance exception" you mean the message that is output to the Debug console? That message is output whenever an exception is thrown. The exception may be caught by code and handled and not allowed to propagate up the stack. TweetSharp may be catching this exception within its code and handling in some way so it never reaches your catch block
This is normal and only the debugger displays this message. If this is a problem for you in some way (other than the message displaying in the Output window), please provide more detail.
I was looking something else, really, but this cought my eye. If you are planning to rethrow exception then you want to replace this
catch (WebException e) { throw e; }
with this so you won't mess up the stacktrace.
catch (WebException e) { throw; }