Can the use of Try in Delphi when misused be a trap?

Question

Once a programmer saw my codes and praised me for making use of Try, I confess that I was not thrilled by the praise for finding that the use of Try is not a simple way to solve exceptions, I see the use of Trys indiscriminately even replacing a if which could verify the consistency of the data before any execution, for example:

try
  ...
  a := 1;
  b := 0;
  res := a / b;
except
  ...
  ShowMessage('Valor invalido'); // Nesse exemplo vamos ter que ficar caçando se o valor invalido é de a ou b
end;

When it should be:

  a := 1;
  b := 0;
  if (b <= 0) then
  begin
    ShowMessage('Valor invalido');
  end
  else
  begin
    res := a / b;
  end;

Using the try to capture exceptions or destroy a memory object (with finally) i fully agree the final often we do not think of all possibilities within a routine, but the use of the try thoughtless way can bring big headaches as well as the with Delphi option I abstain whenever I can, no matter in having to type more.

I am very far from being a doctor in programming I say that I do what I can, thank God I have been able to solve the problems proposed to me, but sometimes there are some whys in the head and we need to raise the question before the programmers friends to make the need for a clearer function in our mind.

I would like to know the position of colleagues on the use of Try.

Answer 1

In fact, according to my observation, about 90 to 99% of programmers think that the try solve problems, when often what happens is the opposite.

There are languages that have a culture of using exceptions, others use only when it’s really useful. I don’t know what it’s like at Delphi, and I usually recommend following the culture of language most of the time. But you can’t do anything too wrong either.

No one will die from using excess exceptions (maybe in a medical application :) ), but ideally avoid exceptions.

When to use

• I don’t care much when the exception is used to indicate programming error, I think it should be something else, but it’s worth it. Just becomes a problem when the programmer thinks he should capture this exception thinking it helps in something. Of course capture in general for power log in it’s okay, but this is only necessary at one point of application.

• If the error is catastrophic no use capturing the error, you cannot do anything useful.

• If the API you use only allows you to detect errors with exception does not have much to do, you have to capture to decide what to do. Capture the specific exception always!

• If you detect the problem to make a later decision that depends on the previous state can generate a running condition, then the exception is a good.

• If something should not occur, never, but you know it can occur, the exception was created precisely for this, hence her name. In general this comes from something external to the application.

• In some cases to simplify the development one can abuse exception to indicate normal flow, but this is wrong, If there is a reasonable chance of going wrong, and that reasonable does not need to be 50%, can be 1, 2 or 3%, can be more, or less, has no magic number, the exception is probably exaggerated. That’s why is not used for validation and flow control.

There are cases where the code gets much more complicated. Exception is a goto that you don’t know where you’re going.

Division by zero

The example of the question is a programming error and should not use an exception. Use a if before the operation to ensure that the divisor is not 0, so the second option is usually better.

I do not know in Delphi the quality of exceptions implementation. It would be good to do a test (the proper way) which is faster when there is no fault, when there is little and much too.

What is the chance of the divisor being 0? If the answer is "never should" or "almost never", the exception may be more interesting, if you have a modern implementation that works with an auxiliary table of capture points and not a stack where there is capture.

If you know that you will have some cases that is the same, then there’s a good chance that the error executions are so slow, and the catch table-based exception release is absurdly slow, the performance is likely to get worse.

If there is any chance the splitter will change during processing (multithreading) also it is better to let the error occur to avoid the race condition.

I would only use the exception capture in this case if really the performance is clearly very good in almost all use cases.

Performance

On capture stack has cost even if it does not throw the exception, to the point that a if should cost cheaper, because the if allows optimizations, the try inhibit them. But the launch cost is very low, however, higher than indicate the error otherwise.

Test performance as a whole, because inhibiting optimizations can bring real degradations not noticeable in a very specific test.

often we do not think of all possibilities within a routine.

That’s the problem, programming is the opposite of that. Probably the hint you received has to do with this: "put try-except and rest assured that any mistake you make can disguise, "which even hides relevant information to help solve the problem.

When the person capture "to stay quiet" probably captures a more general exception, meaning there’s no way of knowing or what to do with it. They often perform something that doesn’t make any sense because she captured everything but dealt with something specific.

See more.

What are Exceptions?