Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 185
  • Last Modified:

Exception handling

Well, in my application I've got some (to keep things simple, let's say) objects: a data manager, a data acquisition module...
Everyone of them has its own exception base class and has to handle the exceptions. Now the question: where is the best place to put the 'try except end'? I don't want to put it around the Application.Run because (as said) every object has to handle its own exceptions. Any opinions?

TIA
0
j42
Asked:
j42
2 Solutions
 
xxflipCommented:
Try except should be used in critacal areas, places where you can't be sure if you're getting the results you need.
Inside the objects events is the place for you try ... except routine, so you would have something like:


procedure SomethingAfterOpen(sender:TObject);
begin

  try
    ...do something
  except
    on e:Exception do {handle exception};
  end;

  ....

  try
    ...do something
  except
    on e:Exception do {handle exception};
  end;

end;

Just keep in mind that if you have several operations inside a try ... except, any one of them can cause an exception, in this case you should analize the exception type to handle it correctly.
0
 
j42Author Commented:
Hmm...

I will not put the 'try...' in every public method of my objects.
For clarification:
  - I raise the exception in case of a condition I can't go ahead
  - in my 'try...' statement I want to tidy up to be able to go ahead (maybe some additional user input)
Something like 'No floppy in drive A. Continue, ignore or abort?'
0
 
j42Author Commented:
> Inside the objects events...
I use the MVC pattern, thus the visual stuff is just a thin layer and I don't want it to deal with exceptions.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
GloomyFriarCommented:
...
Application.OnException := _FOnAppException;
...

procedure TMainForm._FOnAppException(Sender: TObject; E: Exception);
begin
 try
  ShowMessage('Exception: ' + E.Message);
 except
 end;
end;

...
0
 
j42Author Commented:
GloomyFriar,

in doing so TMainForm is to be aware of all 'objects' and possible exceptions:

procedure TMainForm._FOnAppExc(...)
begin
  if E is EDataManager then DataManager.OnException(E);
  else if E is EDataAcquisition then DataAcq.OnException(E);
  else if ...
end;

If I add another 'object' (e.g a data filter) I have to remember to extend _FOnAppExc, and I'm short of long term memory ;-)
0
 
BijithCommented:
Suppose in your main form unit is the staring point of any particular modele. EG;

TMainForm = class
private
  procedure DoModule1;
  procedure DoModule2;
  procedure DoModule3;
  procedure DoModule4;

public
 .....
end;
.
.

procedure TMainForm .DoModule1;
begin
  try
    Callthe Module1Function
  except
    HandleExceptionForThisModule
    CheckFor the exceptionclass
  end;
end;

procedure TMainForm .DoModule2;
begin
  try
    Callthe Module2Function
  except
    HandleExceptionForThisModule
    CheckFor the exceptionclass
  end;
end;

procedure TMainForm. DoModule3;
begin
  try
    Callthe Module3Function
  except
   HandleExceptionForThisModule
    CheckFor the exceptionclass
  end;

end;

procedureTMainForm. DoModule4;
begin
  try
    Callthe Module4Function
  except
    HandleExceptionForThisModule
    CheckFor the exceptionclass
  end;

end;

0
 
j42Author Commented:
That's exactly what I want to avoid ;-)
As long as you have only few modules with few public methods and few visual controls which call the methods this will be a very pracmatic way. But every method of the modules may be called by multiple controls. I also have more than on form for the GUI. My main form is just a container with a lot of panels and I set the parent propetry of the sub forms to these panels.
0
 
j42Author Commented:
!!!
> every object has to handle its own exceptions
0
 
DeerBearCommented:
Hi,

From what I read, you're using the Model/View/Controller pattern for your
classes, which is a nice solution.

You could then use an Observer pattern to generate your "error events"
which would be "observed" from appropriate classes.

HTH,

Andrew
0
 
j42Author Commented:
That sounds good, let me think about it.
0
 
GloomyFriarCommented:
>in doing so TMainForm is to be aware of all 'objects' and possible exceptions:
No. Only the unhandled exceptions.
0
 
j42Author Commented:
I like to keep this question open a little bit. Maybe there is some more input. Thanks so far.

GloomyFriar,
> every object has to handle its own exceptions
So i like TMainForm to inform the proper object that a certain exception was raised. I don't want to show just a message and die gracefully. In case of an error I want to gather additional information an keep on running by giving control back to the object that raised the exception.

procedure TMainForm._FOnAppExc(...)
begin
 if E is EDataManager then DataManager.OnException(E);
 else if E is EDataAcquisition then DataAcq.OnException(E);
 else if ...
end;
0
 
j42Author Commented:
I will use the observer pattern to handle my own exceptions and the application event handler to catch everything else.
Thanks again!
0

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now