Re: Is it possible for a try...finally...end construct to fail?
From: Craig Stuntz [TeamB] (cstuntz_at_nospam.please)
Date: 11/25/03
- Next message: Craig Stuntz [TeamB]: "Re: Are Variants slow(ish)?"
- Previous message: Martin James: "Re: Are Variants slow(ish)?"
- In reply to: Mark: "Re: Is it possible for a try...finally...end construct to fail?"
- Next in thread: Mark: "Re: Is it possible for a try...finally...end construct to fail?"
- Reply: Mark: "Re: Is it possible for a try...finally...end construct to fail?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 25 Nov 2003 05:57:02 -0700
Mark wrote:
> Firstly using exceptions is it possible to have error messages like
> assertions where the line number is provided? This would be really
> helpful in some situations.
Yes and no. This feature isn't built in, but there are a number of
third-party packages, such as the Jedi debugging library from the
Delphi JEDI project and MadExcept which provide this. They'll also
give you call stacks and other useful information.
In case you want to know how this works, read this article:
http://www.undu.com/Articles/010729d.html
> I assume the best way to code nested try/except/finally blocks is
> like this:
Actually, the best way to code nested try/except/finally blocks is not
to do it. :) try/finally and try/except are completely different
constructs. Use of try/finally should be *very* common -- use it
whenever action B must happen after action A when there is something in
the middle which might raise an exception.
Use of try/except, on the other hand, should be fairly rare.
Exceptions are not a means of showing a dialog to the user (that's a
side effect of Delphi's global exception handler). Rather, they're a
means of interrupting program flow. The fact that an exception was
raised means that a method's contract was violated. There are two
possible correct responses to an exception being raised:
1. Halt execution -- kick the current instruction pointer to the top
of the call stack. Probably show an error message to the user at this
point.
2. Fix the conditions which caused the error and re-run the method
from the start. For example, if a method is trying to login to the
database and the user has entered an incorrect password, instead of
simply showing them an error you can give them a chance to retype their
password, and then try the login method again.
What this means is that statistically speaking nested
try/except/finally constructs will be rarer than try/except, which
should already be fairly rare.
Note that if your only reason for catching an exception is to show a
different error message than the default you can do this in an
Application.OnException event (or use the TApplicationEvents
component). This gives you the ability to change the exception message
globally -- for the entire app, not just one bit of code.
> Allocmem;
> try
> try
> dosomething;
> except
> // exception code here
> end;
> try
> dosomethingelse;
> except
> // handle the exception - suppress it <g>
> end;
> finally
> freemem;
> end;
With the caveats above and elsewhere in this thread taken into
account, the code above is fine.
-Craig
-- Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH Delphi/InterBase Weblog : http://delphi.weblogs.com InterBase in Multi-tier World -- Use multiple RDMs, IB features in your appserver: http://delphi.weblogs.com/stories/storyReader$195
- Next message: Craig Stuntz [TeamB]: "Re: Are Variants slow(ish)?"
- Previous message: Martin James: "Re: Are Variants slow(ish)?"
- In reply to: Mark: "Re: Is it possible for a try...finally...end construct to fail?"
- Next in thread: Mark: "Re: Is it possible for a try...finally...end construct to fail?"
- Reply: Mark: "Re: Is it possible for a try...finally...end construct to fail?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|