Re: Exception handling?

Goran wrote:


This is why I said, as with the simple fopen(), the most typical
errors of "interest" are literally related to:

     not found
     bad input
     locking
     sharing

any other error is more system or hardware related.


Could be, sure. For me, for example, logging functions:

    FILE *fv = fopen(filename, "at");
    if (fv) {
       fprintf(fv,whatever);
       fclose(fv);
    }

but there are cases where in my more elaborate class based logging
class, where there is rotating of files, etc, there are some error
checking, including a general catch all for the valist.


Not quite sure if I follow, and if I did, I would not be among the
90%. I generally focus contain errors at the point of functionality. I
really use a catch all, this is more "recent" for me and only where
required, i.e, ODBC classes. I make extensive use of exceptions for
our RTE for our Wildcat! BASIC p-code language, where like a .NET
environment, you must capture programmer faults so it won't bring the
Wildcat! Interactive NET server "OS" per se.

Even in our WCBASIC language were we offer CATCH exception trapping,
the same issues apply, - do you use specific catch traps or catch
alls. It depends.

For example, since our system deals with communications, WCX (compiled
wcBASIC applets) has "Connection Drops" concepts.

If the programmer did not add any CATCH blocks, then the RTE will
abort the WCX at the next immediate OP code, cleaning up all its
managed resources.

But the programmer who needs graceful trapping or detection of
connection drop can do so as well, and for a CATCH, the RTE will jump
to that block, etc.

But the programmer can also disable the RTE connection drop detection
and allow the applet do the detection or not at all.

The latter might be useful where it knows it will complete and needs
no interruption regardless of a connection drop, or it can do a check
and gracefully clean up and exit.

etc, etc, etc.


Again, it was more of a generalization. As I learn .NET, I will trap
catches around usage of .NET library classes, etc, because I am not
fully aware of all the possible issues with it.

Example, where I started with a global and then fine tune it.

For wcLex, the simple "get going" usage of a socket listener:

    try
    {
       server = new TcpListener(localAddr, port);
       server.Start();
       worker.ReportProgress(0, "- Waiting for clients");
       uint nClientTid = 0;
       while (true)
       {
         nClientTid++;
         ClientData ctcp = new ClientData(
                             server.AcceptTcpClient().Client,
                             nClientTid);
         worker.ReportProgress(1, ctcp);
        }
    }
    catch (SocketException err)
    {
      // 10004 expected for breaking socket handle
      if (err.ErrorCode != 10004)
      {
        worker.ReportProgress(0,
           String.Format("! SocketException: ErrorCode: {0}",
                           err.ErrorCode));
      }
    }
    finally
    {
      // Stop listening for new clients.
      worker.ReportProgress(0, "- Ending");
      server.Stop();
    }

The above was quick original code, and then the fine tuned to handled
to bunch of scenarios, some which only came after KNOWING what part of
the socket class does what.

For example, when it came to testing conflictive bindings (two
instances of wcLEX trying to open the same address and port), the
CATCH ALL showed the socket exception.

The question was, which call throw it?

Was it?

       server = new TcpListener(localAddr, port);

or was it?

       server.Start();

It was the latter, so a try was added around it to catch that specific
  error event.

Since the above was part of the BackgroundWorker_DoWork event, I also
spend time to send feedback to the calling RunWorkerAsync() to above
the starting of the server. Throwing exceptions in dowork did not get
caught. I need to learn about that aspect of it. But I used mutexes
to signal a StartupOK event. Here is the code, unchanged:

         private void backgroundWorkerServer_DoWork(object sender,
DoWorkEventArgs e)
         {
             BackgroundWorker worker = sender as BackgroundWorker;
             try
             {
                 worker.ReportProgress(0, "* Starting NNTP Server");
                 server = new TcpListener(localAddr, port);
                 server.Start();
                 StartupOk = true;
                 StartupEvent.Set();
             }
             catch (SocketException err)
             {
                 if (err.SocketErrorCode ==
SocketError.AddressAlreadyInUse)
                 {
                     worker.ReportProgress(0, String.Format("! Socket
Address/Port already in use: {0}:{1}",mySettings.IPAddress,
mySettings.PortNumber));
                 }
                 else
                 {
                     worker.ReportProgress(0, String.Format("! Init
SocketException: ErrorCode: {0} {1}", err.ErrorCode,
err.SocketErrorCode));
                 }
                 StartupEvent.Set();
                 return;
             }

             try
             {
                 worker.ReportProgress(0, "- Waiting for clients");
                 uint nClientTid = 0;
                 while (true)
                 {
                     nClientTid++;
                     ClientData ctcp = new
ClientData(server.AcceptTcpClient().Client, nClientTid, mySettings);
                     worker.ReportProgress(1, ctcp);
                 }
             }
             catch (SocketException err)
             {
                 if (err.ErrorCode != 10004)
                 {
                     worker.ReportProgress(0, String.Format("!
SocketException: ErrorCode: {0}", err.ErrorCode));
                 }
             }
             finally
             {
                 // Stop listening for new clients.
                 worker.ReportProgress(0, "- Ending");
                 ShutDownEvent.Set();
                 server.Stop();
             }
         }

Note, the ShutDownEvent mutex was used to synchronize an EXE shutdown
and the logging of the status becoming invalid when the application
thread is exited and thats because I switched to using in Program.cs

    Form1 form1 = new Form1();
    Application.Run();
    GC.KeepAlive(form1);

to control the flickering of the always startup visible window made
hidden when the notifyicon is active.

So the point is, that even when you do know how the exceptions and
flow should be done, it can CHANGE depending on other factors.

See the thread where I talked about the LiveID SDK example Live ID DLL
binding with the EXE no longer applies when the DLL is bound to a
helper DLL. There the exception logic must change.


What IDE do you use?

--
HLS