Funktionale Methode vs Exception Handling

[Maja967]

Hallo,

ich würde gerne Funktionale Methoden entwerfen um mir und meinen Kollegen das Leben einfacher zu machen.

BSP: Methode holt aus einer Internen Tabelle eines Statsichen Attributes einen Satz und liefert diesen
and den Aufrufer zurück:

Variante A:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1.  CALL METHOD bla2->GET_SATZ
2.    EXPORTING
3.      I_SHERKU  = va_sherku
4.      I_BUKRS   = va_bukrs
5.    RECEIVING
6.      E_SATZ    =  ab_satz
7.    EXCEPTIONS
8.      NOT_FOUND = 1
9.      others    = 2
10.          .
11.  IF SY-SUBRC <> 0.
12. *  MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
13. *             WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
14.  ENDIF.

GeSHi ©

und Variante B:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1.  try.
2.    ab_satz = bla2->get_satz&#40; i_sherku = va_sherku i_bukrs = va_bukrs &#41;.
3.  
4. *   CATCH ??????
5.  ENDTRY.
6.  

GeSHi ©

ich würde Variante b) präferieren, da diese den gesamten Quellcode nicht so auseinander reißt ... jedoch habe ich keine Ahnung wie ich das Exception Handling lösen könnte .... ich vermute das wird dann genauso wie bei A ?

[Bianka4768]

Hallo cut1,
nachfolgend ein kleines Testprogramm (sinn- und funktionslos, aber möglichst deine Benennungen aufgegriffen):

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. REPORT  zrt_test.
2. *
3. TYPES:
4.   sherku TYPE kokrs.
5. *
6. START-OF-SELECTION.
7.   PERFORM s_o_s.
8. *---Error classes
9. CLASS cx_not_found DEFINITION
10.   INHERITING FROM cx_static_check FINAL.
11. ENDCLASS.                    "cx_not_found  DEFINITIO
12. *
13. CLASS cx_others DEFINITION
14.   INHERITING FROM cx_static_check FINAL.
15. ENDCLASS.                    "cx_others  DEFINITIO
16. *
17. CLASS test DEFINITION.
18.   PUBLIC SECTION.
19.     METHODS:
20.       get_satz
21.         IMPORTING
22.           i_sherku TYPE sherku
23.           i_bukrs TYPE bukrs
24.         RETURNING
25.           value&#40;e_satz&#41; TYPE i
26.         RAISING
27.           cx_not_found
28.           cx_others.
29. ENDCLASS.                    "test DEFINITION
30. *
31. CLASS test IMPLEMENTATION.
32.   METHOD get_satz.
33.     IF i_sherku = i_bukrs.
34.       RAISE EXCEPTION TYPE cx_others.
35.     ELSEIF i_sherku CN '1234567890' OR i_bukrs CN '1234567890'.
36.       RAISE EXCEPTION TYPE cx_not_found.
37.     ELSE.
38.       e_satz = &#40; i_sherku + i_bukrs &#41; / 3.
39.     ENDIF.
40.   ENDMETHOD.                    "get_satz
41. ENDCLASS.                    "test IMPLEMENTATION
42. *
43. FORM s_o_s.
44.   PERFORM do_it USING '1234' '1234'. "exception cx_others
45.   SKIP 1.
46.   PERFORM do_it USING 'abcd' '1234'. "exception cx_not_found
47.   SKIP 1.
48.   PERFORM do_it USING '0007' '0013'. "ohne exception
49. ENDFORM.                    "s_o_s
50. *
51. FORM do_it USING va_sherku TYPE sherku
52.                  va_bukrs TYPE bukrs.
53.   DATA:
54.     ab_satz TYPE i,
55.     bla2 TYPE REF TO test.
56.  
57.   CREATE OBJECT bla2.
58.   TRY.
59.       ab_satz = bla2->get_satz&#40;
60.         i_sherku = va_sherku i_bukrs = va_bukrs &#41;.
61.       WRITE:
62.         / 'Ergebnis:',ab_satz.
63.     CATCH cx_not_found.
64.       WRITE:
65.         / 'Not found', va_sherku, va_bukrs.
66.     CATCH cx_others.
67.       WRITE:
68.         / 'others'.
69.   ENDTRY.
70. ENDFORM.                    "do_it
71.  

GeSHi ©

MfG

Thomas R.

[Maja967]

Hi Thomas,

erstmal danke für deinen Quellcode -> das ist ja ein Service !!!

In der Hilfe gibt noch folgenden hinweis:

Wenn eine funktionale Methode in einer Operandenposition verwendet wird, können klassenbasierte Ausnahmen, die aus der Methode propagiert werden, wie üblich in einer TRY-Kontrollstruktur behandelt bzw. weiter propagiert werden. Die nicht-klassenbasierten Ausnahmen einer funktionalen Methode können dagegen an Operandenpositionen nicht behandelt werden und führen immer zu einem Laufzeitfehler.

-> Aus meiner Sicht handle ich uns die folgenden Nachteile ein, wenn ich auf Variante b) setze:

- Der Quellcode wird wie bei a) auch auseinander gerissen. also kein Gewinn
bei der Übersichtlichkeit
- der Verwender der Methode muß wissen das es eine Klassenbassierte
ausnahme gibt bzw welche Ausnahmen es gibt. (bei a) sieht er gleich welche Ausnahmen er abfangen kann ...

hmm mir fällt gerade kein Vorteil ein ... hast Du vielleicht noch `ne Idee ?
thx

[Bianka4768]

Hallo cut1,
über Vor- und Nachteile kann man unterschiedlicher Meinung sein, dass kommt auf die Sichtweise an.
Da musst Du einfach zu einem Schluss für Dich kommen. Ich persönlich benutze bei Klassen, die ich implementiere auch klassenbasierte Ausnahmen.

MfG
Thomas R.

[Valentin1455]

Ich verstehe das mit dem außeinanderreisen Nachteil nicht, durch try catch habe ich ja die Möglichkeit den catch Block am Ende des Codes zu schreiben und dort alle Exceptions zu behandeln. Der Vollständigkeit gibt es auch noch Variante c) die aber vermutlich mit a) gleichzusetzen ist nur eine Einsparung von CALL METHOD:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. bla2->get_satz&#40; EXPORTING  i_sherku = va_sherku i_bukrs = va_bukrs
2.                                      RECEIVING re_satz = ab_satz
3.                                      EXCEPTIONS not_found = 1 others = 2 &#41;.
4.             case sy-subrc.
5.                    when 1...
6.  

GeSHi ©

Ich sehe auch eher Vorteile bei Variante b) und der Verwendung von Klassenbasierten Exceptions da nur durch Klassenbasierte Exceptions ein einfacheres Exception Handling nötig ist (gerade Durchschleußen von Exceptions, Eindeutige Exception behandlung am Ende einer Methode,...).
Persönlich nutze ich Variante b), c) wenn es Methoden mit alten Exceptions sind die ich nicht refaktoren möchte bzw. kann und Variante a) versuch ich zu vermeiden. Aber das ist natürlich eine persönliche Meinung.

Gruß,
Flo