rspec/rules/S1674/abap/rule.adoc

== Why is this an issue?

Leaving a ``++CATCH++`` block empty means that the exception in question is neither handled nor passed forward to callers for handling at a higher level. Suppressing errors rather than handling them could lead to unpredictable system behavior and should be avoided.


=== Noncompliant code example

[source,abap]
----
  try.
    if ABS( NUMBER ) > 100.
      write / 'Number is large'.
    endif.
    catch CX_SY_ARITHMETIC_ERROR into OREF.
  endtry.
----


=== Compliant solution

[source,abap]
----
  try.
    if ABS( NUMBER ) > 100.
      write / 'Number is large'.
    endif.
  catch CX_SY_ARITHMETIC_ERROR into OREF.
    write / OREF->GET_TEXT( ).
  endtry.
----


=== Exceptions

When a block contains a comment, it is not considered to be empty.


== Resources

* CWE - https://cwe.mitre.org/data/definitions/391[CWE-391 - Unchecked Error Condition]
* OWASP - https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring[Top 10 2017 Category A10 - Insufficient Logging & Monitoring]


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Either handle this XXX exception or propagate it.


'''
== Comments And Links
(visible only on this page)

=== on 20 Oct 2014, 18:37:01 Ann Campbell wrote:
\[~nicolas.peru] note that this rule that was originally written for ABAP has been extended for Java & an exception added for a comment in the block, making ABAP outdated.

=== on 21 Oct 2014, 15:36:55 Nicolas Peru wrote:
This will be covered by \http://jira.sonarsource.com/browse/RSPEC-108

=== on 27 Feb 2015, 09:57:42 Freddy Mallet wrote:
\[~ann.campbell.2], this spec should be linked to \http://cwe.mitre.org/data/definitions/391.html

=== on 21 Mar 2018, 18:09:23 Alexandre Gigleux wrote:
\[~ann.campbell.2] I don't think this one should be classified as a "Bug Detection". No bug/failure will happen if you keep the code like this.

I think it should be classified as a "Vulnerability Detection". This RSPEC was classified like this in the past (2015) thanks to the tag "security". I don't see any good reason why we changed that. Also, we have an OWASP TOP 10 tag on the RSPEC replacing this one (RSPEC-2486) which is another justification to classify it as a "Vulnerability Detection".


Do you agree? 

=== on 21 Mar 2018, 19:04:23 Ann Campbell wrote:
Fine for me [~alexandre.gigleux]

endif::env-github,rspecator-view[]