Delphi Error handling : Raise vs Exit on try...except...end - delphi-10.1-berlin

Question

Is it safe to call Exit on try except?
Or should I call raise instead?
I tried both example below and at raise example, the trace went through Delphi's internal library code. While exit just exit the procedure and nothing more.
I read that it's better to preserve application stack or queue or something like that. Will calling exit will break that stack?
Example 1 (raise)
SDDatabase1.StartTransaction;
Try
SDQuery1.ApplyUpdates;
SDDatabase1.Commit;
SDQuery1.CommitUpdates;
Except
SDDatabase1.Rollback;
SDQuery1.RollbackUpdates;
raise;
End;
..............//other codes I don't want to execute
Example 2 (exit)
SDDatabase1.StartTransaction;
Try
SDQuery1.ApplyUpdates;
SDDatabase1.Commit;
SDQuery1.CommitUpdates;
Except
SDDatabase1.Rollback;
SDQuery1.RollbackUpdates;
MessageDlg('Save Failed because: '+E.Message, mtError, [mbOK], 0);
exit;
end;
..............//other codes I don't want to execute

Answer 1

It's rare that alternate options (A vs. B) can be objectively evaluated as one is "always better" than the other. This is why it's important to properly understand the differences and implications of each.
When examined in isolation of a single method both your examples skip the code after the end of the except block. However, one leaves in an exception-state and the other doesn't. This has implications not in the method you write, but in the callers (direct and indirect) of your method.
procedur Caller1;
begin
//...[A]
Caller2;
//...[B]
end;
procedure Caller2;
begin
//...[C]
CallDatabaseMethod; {Will raise; or Exit; based on example chosen}
//...[D]
end;
The key distinction between your 2 examples is:
Example 1 is able to report the failure state up the call-stack.
Example 2 hides this information because the exception handler swallows the exception.
Example 1 would also skip [B] and [D] code. However, Example 2 would execute [B] and [D] code. When you understand this difference, you are then empowered to decide whether [B] and [D] should be executed.
However, I suspect that more often than not, the fact that CallDatabaseMethod failed to do everything correctly suggests that [B] and [D] should not be called. E.g. Suppose the database method updates customer account data and [B] and [D] perform action related to sending the latest statement. You probably don't want to send a statement when the update failed!
That said, if your method can be considered as "successfully completed" in spite of the exception, then by all means swallowing the exception is perfectly acceptable. E.g. Suppose you have a method to "Add a Row" and its post condition is simply that the row must exist in the database. Then if your database return a PK violation, obviously the row does exist. In this case it makes perfect sense to swallow the exception.
You can of course tweak the implementation of example 2 so as to not hide the error.
If your method is written as a function that returns success or failure state as a result, then callers can use this to resolve the aforementioned problems. E.g.
function Caller1: Boolean;
begin
Result := Caller2;
{Caller can decide to skip/ignore/do something different}
if Result then ...
end;
function Caller2: Boolean;
begin
Result := CallDatabaseMethod;
{Caller can decide to skip/ignore/do something different}
if Result then ...
end;
function CallDatabaseMethod: Boolean;
begin
Result := True;
//...
try
//...
except
on E: ExceptionType do
begin
//...
Result := False;
end;
end;
//...
end;
This is the same way the Windows API works. It does have its pros and cons:
Use return codes means caller has to remember to check for errors. (A common source of WinAPI questions on this site involve programmers failing to check for error return by API functions.)
So it's clearly an advantage that the exception model cannot be "ignored" by callers - they will surface eventually, even if it involves crashing the application.
But conversely again there's the disadvantage that the code to ignore exceptions that have been forced upon you is messier.
It's also important to caution against getting into a situation where large amounts of code run inside except blocks1.
The other disadvantage of structure exception handling is that it does have a significant performance overhead, so ideally you don't want to raise and handle them too often.
I recommend that the best approach is to determine which kinds of errors can be considered "normal" and ensure this is processed using explicit error results rather than exceptions. Certainly instances of 1 above are prime candidates.
Finally David has already flagged concerns with your message dialog in example 2. So this comment is on the assumption that this code always runs in a user context.
I understand the urge to show the message immediately. You have context that is lost by the time the exception propagates to the application level handler. One option to consider is using Abort which simply raises an EAbort exception.
try
//...
except
on E: ExceptionType do
begin
MessageDlg(...);
Abort;
end;
end;
The default application exception should ignore this exception and not display a message. If you have your own handler, you should similarly check the exception class before displaying any message.
As a side note I'd like to consider a particular sentence in the question.
I read that it's better to preserve application stack or queue or something like that.
Obviously if you're not sure about what you read, it's difficult explain it to you. You might already have a clearer picture based on earlier parts of my answer.
However, it might be referring to a different problem with another approach to exception handling. Raising a new exception. (You avoid this problem with raise; because it re-raises the original exception in original context.) This is the sort of thing is done to provide "more meaningful error message - similar to your example 2.
try
except
raise EOtherError.Create('My Message');
end;
The problem with the above is that when this exception eventually propagates to the application handler you've lost the original class; original exception address; and the original message. This approach often results in a clearer error to the user: e.g. "Unable to open file filename" but hides information that might have been useful in troubleshooting. E.g. Was it a disk error, was file not file, was it access permission error.
So: an important thing to think about whenever handling errors (no matter what approach you use) is: will there be enough information to resolve an error should it occur?

Answer 2

Both are safe in principle, but it's impossible to recommend one or other approaches. It depends on your design intentions. You have to decide which is appropriate given the intended usage of the code.
If you handle the exception in this code, and leave the function with exit, then the execution returns to the calling function, and it has no inkling of whether or not the function succeeded or failed. This may be problematic.
If you re-raise the exception, execution will move to the next suitable exception handler up the call stack, passing through any finally blocks along the way.
So, behaviour will differ, and it's down to you to decide which you want.
It is a common beginner's mistake to attempt to handle exceptions further down the call stack than is ideal. For example, suppose you want your code to be used in both a GUI app and a non-visual app. Your use of MessageDlg would not be appropriate in a non-visual app.
In a GUI app it is common for most actions to be in response to user input, for instance a button press. Exceptions typically should result in the entire operation being aborted. In which case you should not attempt to handle exceptions at all. Let them pass to the application level exception handler.
Finally, your code treats all exceptions in the same way. This is often ill-advised. For instance, an access violation should surely be treated differently from a database error.