What's finally keyword good for?

[Peter Morris]

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.

Logging is an additional idea for tracking the bug, you still shouldn't let
your app continue after unknown circumstances occurred.

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

A session is state, so is a database. In fact, the data in the DB is the
worst kind of state you can screw up.

 

[Ollis]

Logging is an additional idea for tracking the bug, you still shouldn't let
your app continue after unknown circumstances occurred.

Really man, there is nothing you can tell me about this, as I have been down
all the roads in my 30 plus years of developing software business solutions
in IT. It's moot as far as I am concerned.

A session is state, so is a database. In fact, the data in the DB is the
worst kind of state you can screw up.

Reading from a database is less critical than writing to a database. That
was the example that was shown to you, where as, asynchronous Web service
calls from the UI tier to the BL tier and BL tier to the DAL tier to
retrive data for the UI can continue and the form is populated, even though
a given Web service call terminated, the form continued its load process,
and the process as a whole was not terminated for the form.

And of course writing to a database is very critiical. That's why one could
put a solution into a transactional mode to write to database tables or
across databases, with the solution being aware of abort conditions, where as
transactions are commited as a whole if all transactions are suscessful or
all transactions are rolled back if any given part of the transaction process
aborted.

As far as state with a Web solution, one can keep state on a Web form as far
as that is concered, one can keep state on a Web state server or keep state
using MS SQL server as a Web state server for a Web solution, but a Web
solution in itself is not a stateful solution.

The Web solution doesn't keep state continusouly or an unbroken state like
a Windows desktop or other such type of solutions. And state between the Web
server and the Web clint is dropped each time on the round trip between the
two so the the Web server can service requests from other Web clients.

 

[Ollis]

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.

One still has to know what exception to look at if handled elsewhere. So one
knows it at the point of incident or one knows it at a later time in the
process, but one has to know what the execption was about to take the proper
program execution path with the exception.

And every last bit of exception handling can be dealt with using a test
plan, with solution being tested based what is expected on success and what
is expected on failure with each path tested and expected results.

There is no execue not to know this, other than, one is not given the time
to do it.

 

[Peter Morris]

Really man, there is nothing you can tell me about this

I always say 2 things.
01: You can learn at least 1 thing from everyone.
02: A person who wont listen is a person who wont learn.

 

[Ollis]

I always say 2 things.
01: You can learn at least 1 thing from everyone.
02: A person who wont listen is a person who wont learn.

If I saw some vakue in what you were talking about, I probably would. You
have shown me nothing that I don't already know.

 

[Peter Morris]

I was commenting on your statement

"Really man, there is nothing you can tell me about this,"


I made that quite clear. I am sure there is *something* you could learn
from me about it, we just either don't know what it is or you don't want to
hear it