What's finally keyword good for?

[Ollis]

I started writing multi-user business software for a living in 1994.



Actually it is a fact. If you understand it or not, it is still a fact.

I have been doing this for a long time over 30 years, I don't think
there is too much you can tell me.

Just because you don't know why you need it doesn't mean it has no use

I didn't say that. If I don't need the finally, then I don't need it.

You do this in kind of coding in SOA, do you?

try
{
var fs = new FileStream(fileName, ...........);
//Write stuff to the file
fs.Close();
ZipTheFileUp(); bad = false;
}
catch (IOException)
{ bad = true;
}

if (!bad) File.Delete(fileName);


Where do I need the *finally*?

 

[Peter Morris]

That's the *final* on the successful path. It will always be executed if

successful.

Yes, you are absolutely correct. It will always be executed if everything
is sucessful, but so will this

CreateAFile();
WriteToTheFile();
DeleteTheFile();

That doesn't make it a "finally". The point of finally is that it gets
called whether or not everything is successful. If you still don't feel you
need it that is up to you.

 

[Peter Morris]

if (!bad) File.Delete(fileName);

Where do I need the *finally*?

You are joking, right? You only delete the file if IOException is thrown?
The constructor of FileStream alone can throw any of these exceptions

// System.ArgumentException:
// System.NotSupportedException:
// System.ArgumentNullException:
// System.Security.SecurityException:
// System.IO.FileNotFoundException:
// System.IO.IOException:
// System.IO.DirectoryNotFoundException:
// System.IO.PathTooLongException:
// System.ArgumentOutOfRangeException:

Then what about the exceptions that could be thrown from writing to the
file? Which 3rd party tool does ZipTheFileUp use, and which possible
exceptions can that throw? In your case you are 99% certain to have a stray
corrupt file on your system if you encounter an exception.

and in answer to your question, yes, I do use finally blocks in my
commercial apps.

 

[proxyuser]

It's called poor programming, and one did not know what the abort
conditions
were out of the gate.

No, it's not. It doesn't matter if you know the abort conditions or not.
The point is, you might want to propagate an exception for handling
somewhere else.

 

[Ollis]

You are joking, right? You only delete the file if IOException is thrown?
The constructor of FileStream alone can throw any of these exceptions

I really didn't pay too much attention to the code, only to indicate that
where is the *finally* needed, which is not needed, period.

// System.ArgumentException:
// System.NotSupportedException:
// System.ArgumentNullException:
// System.Security.SecurityException:
// System.IO.FileNotFoundException:
// System.IO.IOException:
// System.IO.DirectoryNotFoundException:
// System.IO.PathTooLongException:
// System.ArgumentOutOfRangeException:

Then what about the exceptions that could be thrown from writing to the
file? Which 3rd party tool does ZipTheFileUp use, and which possible
exceptions can that throw? In your case you are 99% certain to have a stray
corrupt file on your system if you encounter an exception.

Why would I care about this? The only thing I would care about is (Exception
ex) to catch all execptions. And I don't write ZIP files period, not in SOA
or N-tier application design. If anything, I am using a 3rd party compression
tool and doing it in memeory.

and in answer to your question, yes, I do use finally blocks in my
commercial apps.

Really? So, I guess you have not gone onsite at a client site that had
existing SOA and N-Tier framework architecture already in use, and there is
not a *finally* anywhere to be seen.


And I am going to say this again. One shoe doesn't fit all.

 

[jake]

You are joking, right?  You only delete the file if IOException is thrown?
The constructor of FileStream alone can throw any of these exceptions

  //   System.ArgumentException:
  //   System.NotSupportedException:
  //   System.ArgumentNullException:
  //   System.Security.SecurityException:
  //   System.IO.FileNotFoundException:
  //   System.IO.IOException:
  //   System.IO.DirectoryNotFoundException:
  //   System.IO.PathTooLongException:
  //   System.ArgumentOutOfRangeException:

Then what about the exceptions that could be thrown from writing to the
file?  Which 3rd party tool does ZipTheFileUp use, and which possible
exceptions can that throw?  In your case you are 99% certain to have a stray
corrupt file on your system if you encounter an exception.

and in answer to your question, yes, I do use finally blocks in my
commercial apps.

I am in neither camp. I am just curious as to the following:

try
{
//something
}
catch
{
//general "catch" all
//no "throw"s are executed here
}
//no "finally" block
foo();

Wouldn't foo() execute no matter what? Or, am I way off-base here?
I am still learning,
jake

 

[Ollis]

I am in neither camp. I am just curious as to the following:

try
{
//something
}
catch
{
//general "catch" all
//no "throw"s are executed here
}
//no "finally" block
foo();

Wouldn't foo() execute no matter what? Or, am I way off-base here?
I am still learning,
jake

Yes, foo() is going to be execuited, unless you use a conditional statement
not to execute foo().

The condition could be set on try and successful execution or on the catch
with a unsuccessful execution to execute foo() or not to execute foo().

One uses a *finally* based on the need to use a *finally*. If one doesn't
have the need to use the finally, then why use it?

 

[Registered User]

I have been doing this for a long time over 30 years, I don't think
there is too much you can tell me.

I didn't say that. If I don't need the finally, then I don't need it.

You do this in kind of coding in SOA, do you?


if (!bad) File.Delete(fileName);


Where do I need the *finally*?

In the code above if an exception occurs while writing to the file,
does the stream get closed?

var fs = new FileStream(...);
try
{
//Write stuff to the file
}
catch
{
// specific exception handling
bad = true;
}
finally
{
fs.Close();
}

if (!bad)
{
ZipTheFileUp();
File.Delete(fileName);
}

regards
A.G.

 

[Ollis]

In the code above if an exception occurs while writing to the file,
does the stream get closed?

var fs = new FileStream(...);
try
{
//Write stuff to the file
}
catch
{
// specific exception handling
bad = true;
}
finally
{
fs.Close();
}

if (!bad)
{
ZipTheFileUp();
File.Delete(fileName);
}

In the code above if an exception occurs while writing to the file,
does the stream get closed?

bad = false;

var fs = new FileStream(...);
try
{
//Write stuff to the file
fs.close();
}
catch
{
// specific exception handling
bad = true;
if (fs is open) fs.close();
}

if (!bad)
{
ZipTheFileUp();
File.Delete(fileName);
}

One can do it anyway he or she wants. Why do I need the *finally*? I don't
need it.

 

[RedLars]

I really didn't pay too much attention to the code, only to indicate that
where is the *finally* needed, which is not needed, period.





Why would I care about this? The only thing I would care about is (Exception
ex) to catch all execptions. And I don't write ZIP files period, not in SOA
or N-tier application design. If anything, I am using a 3rd party compression
tool and doing it in memeory.




Really? So, I guess you have not gone onsite at a client site that had
existing SOA and N-Tier framework architecture already in use, and there is
not a *finally* anywhere to be seen.

And I am going to say this again. One shoe doesn't fit all.

I would highly recommend not using catch(Exception e) - this cause
(hide) a lot of problems.

http://msdn.microsoft.com/en-us/library/ms182137(VS.80).aspx

 

[Dathan]

As you talk of SQL server, what other Exception handling would I be worried
about other than a SQL Exception?

private object GetSqlData(long ID)
try
{
USING SQL connection
{
do some SQL stuff
}}

catch(SQLexception sqlex)
{
if (conncetion open)
{
close connection
}
throw sqlex;

}

---------------------

This is my *finally* path, which for me is always the successful path.

return object;

}

For Sql operations, you're probably right. SqlConnection can
occasionally throw InvalidOperationException, but AFAIK only if you
try to open it while it's already open, or without a valid connection
string set (I know this one from experience. (c: ), which you can
easily write code to check. But what about the case where you're
using an unmanaged resource that doesn't support IDispose? "using"
won't do you any good in that case, and you'll end up duplicating
cleanup code: once per exception handler, plus adding it to the
"successful" path. Alternatively, if you're using a resource that may
throw multiple types of exceptions that you want to handle
differently, "finally" is a nice place to consolidate your cleanup
code.

I'm not suggesting that finally{} is always the right place to put any
code, or that it's always necessary. But I think all but the most
stubborn stalwarts will admit that it has plenty of perfectly valid
use cases.

 

[Registered User]

In the code above if an exception occurs while writing to the file,
does the stream get closed?

bad = false;

var fs = new FileStream(...);
try
{
//Write stuff to the file
fs.close();
}
catch
{
// specific exception handling
bad = true;
if (fs is open) fs.close();
}

if (!bad)
{
ZipTheFileUp();
File.Delete(fileName);
}

One can do it anyway he or she wants. Why do I need the *finally*? I don't
need it.

Yes you're correct, you don't need the finally. The convoluted,
conditional pseudo-code seems to permit the stream to be closed here
or there. That sort of scattered, smothered and covered design doesn't
favor ease of maintenance. But hey you got it 'right' the second time!

Once last riddle for the man under the bridge, what FileStream member
or property do you propose to use in the conditional statement

if (fs is open) fs.close();

regards
A.G.

 

[Peter Morris]

Why would I care about this? The only thing I would care about is
(Exception
ex) to catch all execptions.

and how would you handle the exception?

And I am going to say this again. One shoe doesn't fit all.

So why have the (Exception ex) shoe fit all exceptions?

 

[Peter Morris]

try
{
//something
}
catch
{
//general "catch" all
//no "throw"s are executed here
}
//no "finally" block
foo();

Wouldn't foo() execute no matter what?
<<<

Yes, and no

01: If no exception is thrown then yes, it is executed.
02: You cannot be sure no exception will be thrown, you could at any point
get an OutOfMemoryException for example.

Besides, just because there is no exception thrown today, doesn't mean that
is the case in the future. What happens if in the future the sys-admin
changes some permission that causes the code in the "catch" to fail and
throw an exception? Or what if the method you call in there later
implements a "throw" under certain circumstances?

If it is not imperative for "foo()" to be called then what you have is fine,
if it must be called then you need a finally block, even if you "expect" no
exceptions.

 

[Ollis]

and how would you handle the exception?

Log it, throw it and leave, which is what would be done, if this example of
yours ever made it into a DNA solution in the tiers.

So why have the (Exception ex) shoe fit all exceptions?

Because I didn't care what the execption was, only to log it and leave the
routine on the execption.

 

[Ollis]

Once last riddle for the man under the bridge, what FileStream member
or property do you propose to use in the conditional statement

Would that be that with people like you in this NG, the NG s*u**c*k*.

 

[Peter Morris]

Log it, throw it and leave, which is what would be done, if this example
of
yours ever made it into a DNA solution in the tiers.

If you don't know at which line the exception occurs then you do not know in
which state your application has been left. If you trap explicit exception
types it is because you know to expect them, why they happen, and how to put
your application back into a known state. If you just trap all exceptions
than you have no idea why it occurred nor what state your app is in. As a
consequence your app could continue to run but corrupt important data.

 

[Ollis]

If you don't know at which line the exception occurs then you do not know in
which state your application has been left.

That's why you have a stack trace, and you do know at what line a solution
blew on, which of course is being logged.

The whole world doesn't run based on your filestream example of execption
handleling.

If you trap explicit exception
types it is because you know to expect them, why they happen, and how to put
your application back into a known state.

Well, what if the application is Web application and state is out of the
question, becuase state is lost on each round trip?

What if the application is a Windows Service application, it's calling a Web
service or a WFC Web service and the Web service blows? How is the
application going to hold state? The one thing I do know is that if I log the
execption in the Web service, then I will know.

If you just trap all exceptions
than you have no idea why it occurred nor what state your app is in. As a
consequence your app could continue to run but corrupt important data.

Well, I have seen that.

WEB UI makes asynchronous calls to the Web service to to display data on
the UI , Web service calls the BL tier, the BL makes a call to another Web
service to access the DAL tier, something happened in the tier that actally
blows out the thread using the Web service, the application never stopped
and the UI continues to process to dispaly data on the screen.

That's the way it is, becuase you're not the person in charge. Everything
doesn't fit in one shoe, and the shoe doesn't fit all situations.

We can go on and on about this. I have my way of doing things with exception
handling, and I may or may not use a *finally*. If I don't need the
*finally*, then I am not using it for the sake of using it.

Also, if an exception occurs, one may or may not do anything about it. It
all depends upon the circumstances placed upon someone, not placed upon
someone or the situation.

I am tired of this thread, and I am moving on.

 

[Registered User]

Would that be that with people like you in this NG, the NG s*u**c*k*.

Coming from someone like you I can only take the response as being
complimentary. Thank you.

selah
A.G.

 

[Ollis]

Coming from someone like you I can only take the response as being
complimentary. Thank you.

You mean nothing to me, you are kind of worthless, and you get no thanks
from me. Does that *register*?