Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Error catching?

Status
Not open for further replies.

TheGuardian050

Programmer
Aug 2, 2009
3
CA
I have a console application, which I run through a batch file.

It on rare occasions will crash with different errors, but only rarely. It runs 24 hours a day and the crashes happen only once a week or so, so it's really hard to track them down.

I don't really care though, the batch file is set up to loop the program. The only problem is, even though it's a console app, when it crashes I get a popup window saying OK or Cancel to terminate the program. Either one just restarts the program through the batch file, but what I really want is for the popup to not happen at all and for it to simply loop through the batch file.

Any ideas? Thanks!
 
It would be best for you to figure out what is causing the console app to crash and fix it. Because the popup you reference is caused by that happening, more than likely.

Since it is an intermittent problem, it would be best at this point to analyze the source and see where your potential failure points are and then devise some input data (I assume it does have input data?) to try and duplicate your problems.

Measurement is not management.
 
The app is 17000 lines of code, and the problem is VERY intermittent. I was hoping there was a simple way that I'm not aware of when compiling to make it not do the pop-ups.
 
you can swallow the exception with try...except blocks. But as Glenn sais, it probably best to determine where the crash occurs. That's why I put logging in *every* application I write. all procedures are written in this style:

Code:
procedure TMyObject.DoSomething;
begin
 CreateObjects;
 try
  try
   Log('DoSomething-> doing stuff');
   DoStuff;
  finally
   FreeObjects;
  end;
 except
  on E: Exception do
   Log(Format('function DoSomething failed : "%s"', [E.Message]));
 end;
end;

this way I can rapidly pinpoint any problem that crops up.
also it helps to write unit tests to test code quality.
you are saying it's an intermittent problem, are you using threads?

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
 
Thanks for the code. No, I'm not doing threads, but I'll give this a try!
 
The app is 17000 lines of code, and the problem is VERY intermittent.

Well, I'm not saying to debug the app, but to locate the common choke points in the logic that would possibly cause an error, and then code exceptions for them.

For example, most might just use "strToFloat" when they want to take a float input on a TEdit, but it's necessary to code to handle an error from it, since the user can most certainly type alphabetics in the field (or other characters you don't like). This also goes for reading text as numerics, or a number of other things.

Most don't think about error mitigation, and it's hard to do it (adds a layer of complexity, more time, etc), but especially for production applications it's a big help to do it. Then for something that's 17000 lines, whosrdaddy's suggestion is great for the future.

As well, it's important to do it for debugging, so you don't run into time-consuming headache generators in trying to fix something that would be self-evident if you only coded for it. There's been numerous threads I can think of on this forum that would have been solved easily if the proper error traps were coded.

But still, the best thing is to at this point (for stability overall, both short and long term so you're not fighting fires all the time with this app), is to find all the potential error points and make sure they are being handled in some manner. It'll take some time, yes, but it will pay off down the road in trying to track down errors like you are experiencing.

Measurement is not management.
 
You can take it one step farther in your "except on E: Exception do ..." by capturing the errorcode and passing it to the halt command, like HALT(errorcode); (After logging the error, of course.) So it would look like:
Code:
  try
    ...
  except
    on E: Exception do
    begin
      Log(Format('function DoSomething failed : "%s"', [E.Message]));
      if E.Message = 'some_message' then
        Halt(4)
      else if E.Message = 'some_other_message' then
        Halt(3)
      else if ...
    end
  end;
Then in you batch file you can act accordingly with:
Code:
IF %ERRORLEVEL% EQU 4 goto Error4
IF %ERRORLEVEL% EQU 3 goto Error3
Type "HELP IF | MORE" at the command prompt for more details.


Roo
Delphi Rules!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top