What's finally keyword good for?

  • Thread starter Thread starter K Viltersten
  • Start date Start date
Peter said:
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.
Click to expand...

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 :-)
Click to expand...

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;
}
Click to expand...

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


Where do I need the *finally*?
 
That's the *final* on the successful path. It will always be executed if
successful.
Click to expand...

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.
 
if (!bad) File.Delete(fileName);

Where do I need the *finally*?
Click to expand...

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.
 
Ollis said:
It's called poor programming, and one did not know what the abort
conditions
were out of the gate.
Click to expand...

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.
 
Peter Morris said:
You are joking, right? You only delete the file if IOException is thrown?
The constructor of FileStream alone can throw any of these exceptions
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
 
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.
Click to expand...

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
 
jake said:
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
Click to expand...

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?
 
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*?
Click to expand...
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.
 
Registered User said:
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);
}
Click to expand...
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.
 
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.
Click to expand...

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
 
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;

}
Click to expand...

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.
 
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.
Click to expand...

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();
Click to expand...

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

and how would you handle the exception?

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

So why have the (Exception ex) shoe fit all exceptions?
 
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.
 
Peter Morris said:
and how would you handle the exception?
Click to expand...


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?
Click to expand...

Because I didn't care what the execption was, only to log it and leave the
routine on the execption.
 
Once last riddle for the man under the bridge, what FileStream member
or property do you propose to use in the conditional statement
Click to expand...

Would that be that with people like you in this NG, the NG s*u**c*k*.
 
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.
Click to expand...

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.
 
Peter Morris said:
If you don't know at which line the exception occurs then you do not know in
which state your application has been left.
Click to expand...

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.
Click to expand...

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.
Click to expand...


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.
 
Would that be that with people like you in this NG, the NG s*u**c*k*.
Click to expand...

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

selah
A.G.
 
Registered said:
Coming from someone like you I can only take the response as being
complimentary. Thank you.
Click to expand...

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