Align keywords with second word of first line: RAISE EXCEPTION with EXPORTING

[sap]

Align keywords with second word of first line: RAISE EXCEPTION with EXPORTING

[jmgrassau]

Hi Fabian,

with the next release, the cleanup rule "Align parameters and components" will also consider the EXPORTING ... section in "RAISE EXCEPTION … MESSAGE … EXPORTING …" and "RAISE SHORTDUMP … MESSAGE … EXPORTING …" cases:

The position of EXPORTING itself depends on the context, so if MESSAGE is in a different place (e.g. because the rule "Align keywords with second word of first line" is not activated), then EXPORTING will be positioned accordingly:

This does not align the MESSAGE section itself – I guess that would be worth a rule of its own…

Kind regards,
Jörg-Michael

[jmgrassau]

Hi Fabian,

looks like you have a sharp eye for inconsistencies :-), that's great!

For some background, the "Align keywords with second word of first line" rule indeed uses the approach "align with second keyword, unless a better, more specific rule applies". The main idea is that in some cases, multi-line commands confuse the eye w.r.t. where the command starts or ends:

  LOOP AT mo_item_manager->get_all_items( )
    ASSIGNING FIELD-SYMBOL(<lo_item>).
    INSERT VALUE #( item_id       = <lo_item>->ms_data-item_id
                    item_category = if_any_interface=>cos_item_type-empty )
      INTO TABLE lth_any_hash_table.
  ENDLOOP. 

Looking at this, the first thought that comes to my mind is: "Wait, is there an 'ASSIGNING' command in ABAP?", before I then realize that this line is not a stand-alone command at the beginning of the LOOP body, but rather continues the LOOP command.

So, in some cases, it helps readability to indent the second, third etc. line far enough; and aligning it with the second word of the first line usually looks nice and tidy (the idea is from our team programming guideline).

However, RAISE EXCEPTION is a bit of an in-between case, because in its simple form, it is actually like a method call, passing parameters to the constructor of the exception class (similar to CREATE OBJECT). Preferring functional style, you would usually want to replace …

    RAISE EXCEPTION TYPE zabc_path_exception
          EXPORTING
            previous = exception.

… with …

    RAISE EXCEPTION NEW zabc_path_exception( previous = exception ).

… which is exactly what the "Replace RAISE … TYPE with RAISE … NEW" rule does. However, that is not possible with the MESSAGE addition, and that's why RAISE EXCEPTION is handled a bit inconsistently.

Therefore, you could argue that the inconsistency lies a bit in the RAISE EXCEPTION syntax itself. I do agree, however, that the "Align parameters and components" rule should apply to "RAISE EXCEPTION TYPE … MESSAGE … EXPORTING", too, and will enhance it accordingly!

Kind regards,
Jörg-Michael

P.S.: MESSAGE with all its variants and additions would in itself of course be worth a cleanup rule. It's not like we have already run out of ideas…

[fabianlupa]

Thanks! After writing this I also thought about other use cases for consistency and indeed some do feel weird if the logic were applied though I cannot think of an objective way to rule them out. Like this seems unneccessary and doesn't provide any benefit.

CLASS my_class
  DEFINITION
  CREATE PRIVATE
  PUBLIC.

CLASS my_class
      DEFINITION
      CREATE PRIVATE
      PUBLIC.

[jmgrassau]

Hi Fabian,

this should now work with version 1.4.0 (released today)!

Kind regards,
Jörg-Michael