this is just messy IMO

Ollie

Hi Rakesh,

This is great idea!

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Hi Robby,

I don't know about MFC C++ programmers. But Effiel for .NET has implemented
what I'm currently proposing.

See:
http://docs.eiffel.com/eiffelstudio/technologies/dotnet/eiffel_dotnet_language/2
0_language/60_exception_mechanism.html

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Mattias,

You cannot catch that the power goes down is almost always my simplified
answer on this.

Is up to you if you agree that with me

Cor

I don't agree, and I know about the atomicity problem (the fact that the
file may disappear between your Exists test and the open call).

My guidelines are the following:

1) You MUST use a try/finally (or better a "using" block) to guarantee that
the file will be closed in a predictable way.

2) In normal circumstances (99.99% of the time), you should NOT introduce
any catch clause around file open logic, you should let exceptions percolate
to a generic catchall that reports and logs all exceptions.

3) There are situations where you should test with Exists before opening and
there are other situations where you should NOT test with Exists.

4) There are some VERY RARE situations where you need both the Exists test
and a try/catch, but normally you don't.

Some words of explanation:

1) I am sure that everybody will agree about this one.

2, 3, and 4). It all boils down to how you draw the line between a "normal"
context of execution and an "abnormal" one.

Here are some assumptions that I consider to be true in a "normal" context
of execution:

a) The vital files that my installer has placed in the Program Files area
have not been deleted by the user. If they have, the user will have to fix
it by restauring the file or reinstalling the application.

b) There is no "sweeper" program that runs in the background and deletes
files in an unpredictable way. So, if my application creates a file and then
tries to open it a few seconds later, the file should still be there. If
there is such a sweeper program then the user should identify the culprit
(virus?) and put his system back into a stable mode.

c) The application may use some optional files. In this case, the
application will have to test if the file exists or not before opening it,
and the application will have a fallback strategy (like using some default
values instead of values read from the file).

d) There may be special situations where the application will use files to
exchange data with another application. If the synchronization protocol
between the two apps is weak, the application must be ready to handle the
case where the file gets deleted by the other app in unpredictable ways (for
example between a call to Exists and a call to open).

So, here are the coding patterns that I recommend in some common scenarios:

When the application needs to open a "vital" file created by the installer,
or a temp file that another method has created just before (cases a and b),
the correct pattern is:
   using (Stream stream = File.Open(filename, ...)) {
DoSomething(stream); }

When the application need to work with an "optional" file (case c), the
correct pattern is:
   if (File.Exists(filename))
       using (Stream stream = File.Open(finename, ...)) {
DoSomething(stream); }
   else
       UseDefaultValues();
In the very special situation described in d) above (and I would not
recommend using this kind of interprocess communication but sometimes this
is the only way to deal with legacy apps), The correct pattern is:

  using (Stream stream = MyFileHelper.TryOpen(filename, ...))
   {
       if (stream != null)
           DoSomething(stream);
   }

where MyFileHelper.TryOpen is coded as:

Stream TryOpen(filename, ...)
{
   if (!File.Exists(string filename))
       return null;
   try {
       return File.Open(filename, ...);
   }
   catch (FileNotFoundException ex)
   {
       return null;
   }
}

With these guidelines, you get simple, understandable application code
(instead of a big mess of try/catch), and you know exactly the assumptions
that the developer makes about the files (is it a file that should always
exist? and if it does not, this is just as abnormal as if the disk was bad,
or is it an optional file? or is it a file that may disappear in
unpredictable ways?).

In short, the pattern that you will be using depends on the assumptions that
you make about your operating environment. In many cases, the simplest
pattern (just opening the file without any Exists test nor any catch clause)
is the one to use.

Bruno.

well, if such a keyword is introduced, it'd compile down to probably the
exact same IL as the goto variant that it supports already.  it'd be nothing
more than syntactic sugar so to speak.  and I really don't see enough use to
justify adding a whole new keyword.

not to mention generally speaking, using exceptions to control program flow
is just a very bad idea.

Why only two submissions:

Do While ListIndex < FileList.Count
  If ProcessCompleted(FileList(ListIndex)) Then Exit Do
  ListIndex += 1
Loop
 
Here the called process returns a Boolean True on success, and
leaves the error trapping to the actual file handling code....

The point is that a little different design may do the job in a more
straight forward manner.  As others indicated, you are advocating
the opportunity to add hard to follow (recursive) logic.  Why not
just use a simpler design?

LFS

Neither. They're both extremely ugly.  The problem is that you're using
try/catch for a ordinary loop.  

All you're doing here is attempting an action on each available file,
and continuing on first success.  This is a pretty common task...

For Each currentName in strArrayTryList
    if SomethingToDoWithFile(filename)
        return filename
    End If
Next

MessageBox.Show("cannot open any file")

**********

If there must be a try/catch to handle a simple boolean operation, then
that should be encapsulated in the SomethingToDoWithFile function.
There's no need for retry here, and a Retry would make a very simple
operation much harder to read.

As somebody else mentioned, exceptions should be exceptional.  They
shouldn't be used as looping constructs.  And I see little use of a new
keyword that is designed to enable bad code.

"Nay Myo Aung" <noemail@noserver.com> schrieb:

A "small variation" is a difference.  Typically you would put the code into
a reusable method.  I think the supposed 'ReTry' statement would make
maintainance of code worse and make understanding and extending code harder.

you are already violating what not to do with exceptions when you write code
blocks as such.  retry will only facilitate such bad practice.

"Nay Myo Aung" <noemail@noserver.com> wrote in

Can you provide a more concrete example?  With what
you provided, I would want to ask, what makes you think
a 'small variation' would work?  Because, if you answer that,
my next question would be why don't you test for that, before
you call on TaskA?

In other words, (for what you offered) determine ahead of time,
which variation will succeed, and use that....

A concrete example would indicate if that could be attempted
(or not).

LFS

I think this thread is example of what could happen if Microsoft implements
the Retry.

An endless thread loop. =0}

Have a great weekend everyone!

David