Empty catch

[jochen-beurer]

This check should not only accept the "#EC EMPTY_CATCH pseudo comment but also the ##no_handler pragma.

[lucasborin]

Unfortunately, code pal supports only one pseudo comment. But, feel free to support us by adding this feature. :)

[jochen-beurer]

So, why does code pal introduce new pseudo comments for existing pragmas?

[lucasborin]

Technically speaking, pragma is an entry delivered in the tables TRPRAGMA and TRPRAGMAT, and both tables have their Delivery Class set as S (system tables delivered by SAP). As the Code Pal is not an SAP standard solution, but so an open-source add-on for the Code Inspector, we are not allowed to append/change these tables.

Anyway, I figured out the ##NO_HANDLER can be translated to the pseudo comment "#EC NO_HANDLER.
So, we could change our default pseudo comment from "#EC EMPTY_CATCH to "#EC NO_HANDLER.

Does anyone see any impediment on it?

[jochen-beurer]

Switching to #EC NO_HANDLER sounds good, because it has always been obeyed by the extended program check. But why not check for ##no_handler, which is part of SAP standard as of 740, when code pal depends on ABAP 740 SP 08?

[estevao-schultz-neto-SAP]

I don't see any impediment in translating it to "#EC NO_HANDLER.
But I also see no problem for the users to use the "#EC EMPTY_CATCH (since a pseudo-comment is different than a pragma by definition). Furthermore, such exemptions should be used in very exceptional cases anyway. I don't see a reason for an empty IF or empty CATCH honestly speaking.

[RolfMantel]

Reasons for an empty Catch include:

1. I trigger a non-essential feature and wish to ensure that exceptions raised will not hit through to my essential application:
   Primary purpose fo the empty "catch" is to catch exceptions.
2. I trigger a sequence of steps, each of which relies on a sucessful previous step .
   Primary purpose of the empty "catch" is to ensure that I skip some code and continue in a controlled way afterwards.

I'd estimate that 5% of my CATCH blocks are empty.

Knowing that the pragma is already necessary, please just consider the validation on an empty catch "delegated" to the ABAP compiler; there is no business purpose of executing the same check twice in two different code validation frameworks.

[estevao-schultz-neto-SAP]

Hi Colleagues,

Usually an empty CATCH is a bad idea because you are "silently swallowing" an error condition and then continuing execution.
Besides, an empty CATCH always leaves the question: Was the exception intentionally not handled or did the programmer forget something?

Occasionally, this might be the right thing to do; however, quite more often is the case that the developer saw an exception, didn't know what to do about it (or wanted to implement it later), and so used an empty catch to silence the problem (this is what we want to avoid).

As you might have noticed, the intention behind this check is to ease code readability. For that, I think it is not of a huge effort to place a RETURN or EXIT inside of a CATCH which is supposed to be empty (thus, a reader or colleague maintaining this code understands your intention clearly).

Yours,
Estevao Schultz-Neto

p.s. Further reading from Forums (as Rolf mentioned that only 5% of his blocks are like this):
"...They're a bad idea in general because it's a truly rare condition where a failure (exceptional condition, more generically) is properly met with NO response whatsoever. On top of that, empty catch blocks are a of a common misuse of the exception handling engine for error checking that should be done preemptively..."

[lucasborin]

Let's get an example: I have a program that runs the payroll. One of the non-essential features of it would be a telemetry routine. If it is not working, I hope the payroll runs anyway.

@RolfMantel: How do you find that the non-essential feature is not working anywhere anymore?

Usually, there is a log feature and the CATCH performs the log insertion. Therefore, no empty catch in the program.

[RolfMantel]

Let's take it that the non-essential feature is nice but has a 1% "infrastructure error" or "data collision" rate. We have 1 million queries per day.

What's the point writing an error log with 10,000 entries per day if the only thing we can learn of the log is that the infrastructre is 99% reliable rather than 100% reliable?

Yes, in a large number of situations, it is meaningful to react on an error. In a large number of situations, it is meaningful to log an error.
But there are some situations where it is meaningful to ignore an error.

[lucasborin]

I am sorry, but I would never recommend anyone to suppress an exception/error/issue.
But ok, it is up to the team to decide when it is relevant or not. That is why the code pal uses pseudo comments.

Now, about the renaming of the pseudo comments from "#EC EMPTY_CATCH to "#EC NO_HANDLER:

1. How can we migrate the current in-use pseudo comments?

Ps: keep in mind code pal supports only one pseudo comment per check.