How to design exceptions classes?

[Martin_Bschen]

This is ind of an open ended question, but i would love to hear your opinion on that subject.

I often see code in the wild where one exception class is defined (say for a package) and every method just throw this exception for a number of different reasons. The different reasons are separated by different text-ids.

For example, if we would formulate the following function in an object-oriented way ...

FUNCTION GUI_DOWNLOAD.
  IMPORTING
    ...
  EXPORTING
    ...
  EXCEPTIONS
    FILE_WRITE_ERROR
    NO_BATCH
    GUI_REFUSE_FILETRANSFER
    INVALID_TYPE

... we would define an exception class with different textid.

Is this the way you should define exceptions?

I feel it is very bad idea, because the exception says nothing by itself and you can't see by the signature of the method what are the possible exception situations. I would rather have an exception class for all the 4 reason shown above. What do you think?

[retired_member]

You might have a look at

http://help.sap.com/abapdocu_751/en/index.htm?file=abenerror_handling_guidl.htm

[raghug]

I have a half written blog about this very topic, this gives me the impetus to finish up... stay tuned!

[raghug]

Here you go, I have finally finished the post! The way that I have outlined in the blog, you don't have redeclare every exception; and, it will also handle some exceptions that you are not otherwise aware of. Handling old-style errors via class based exceptions | SAP Blogs