topic Re: Class Based Exceptions - Emperors New Clothes in Application Development and Automation Discussions

Class Based Exceptions - Emperors New Clothes

hardyp180 — Thu, 04 Mar 2010 16:24:43 GMT

Many people ask about the technical side of using Class Based Exceptions. The best article I have found to answer that is the one by Gerd Kluger and Christoph Wedler from 2002. That gives a brilliant explanation on the HOW.

What I have always found lacking is the WHY.

I have been too scared to ask this "basic" question in case I got one the of the following arguments

I am too scared to ask a question on the SDN forum asking u201Cwhy are they better than u201Cclassicu201D exceptionsu201D.

Because they are better

Because they are new

Because classic exceptions are u201Cobsoleteu201D

Because they are object orientated

None of which is a proper answer.

If something is clearly ten million times better than something else then it should be possible to come up with examples of WHY without even thinking about it.

The new ABAP editor versus the old one is a fine example. If someone asked me I could list down ten examples off the top of my head. No-one in SDN world seems to be able to do that with Class Based Exceptions. They just state how they work and say u201Cand thatu2019s betteru201D.

I am looking for a benefit like

- you need less code to achieve the same result

- it is clearer what is going on

- you can catch an error you canu2019t catch usually

u2026. With an actual code sample to shove the benefit right into my face.

Edited by: Rob Burbank on Mar 4, 2010 5:43 PM

Re: Class Based Exceptions - Emperors New Clothes

Sandra_Rossi — Thu, 04 Mar 2010 22:39:53 GMT

I'm disappointed to not see any question finally (may I dare tell you: you shouldn't mark this post as a question )

Well, this post would be perfect as a blog.

Re: Class Based Exceptions - Emperors New Clothes

Former Member — Thu, 04 Mar 2010 22:46:04 GMT

Here are some quotes from the article above with quotes by me. It is not my intention to slag off the authors of the article, which as I said was the best I have ever read on the subject, I just use them as examples of the type of justifications I have often read about using the new exceptions.

u201CIt is often the case however, that instead of handling exceptions, you want to handle only certain ones and pass the rest to the calleru201D. Why? Why wouldnu2019t you want to handle them? An example would be great.

u201CThere is no way to group similar errors, like there is with runtime errors u2026. You cannot define your own error groupsu201D. Why would you want to? Again, an example might make sense of this.

u201CThere is no additional information accompanying the exceptionu2026..u201D u2013 once again, what could this be used for? They go on to say that class based exceptions solve a problem that was not there before class based exceptions existed, and therefore they are a good thing, a circular argument like the "because they are good" justification mentioned above.

u201CWithin the CLEANUP clause, the system can, for example, restore an object to a consistent state or release external resourcesu201D. What do they mean by this? I have no idea. Yet again, an example would be good.

The article manage to ALMOST explain when to use the three types of exceptions u2013 based on CX_STATIC_CHECK, CX_DYNAMIC_CHECK and CX_NO_CHECK. The article clearly explains HOW each works and how the system treats it, and mention if you use the wrong one the world ends, but once again examples are needed over and above division by zero.

In conclusion, I throw a challenge to the world. Give me just one code example which clearly shows me the benefit of using class based exceptions as opposed to the "old" method. if it's that obvious this shouldn;t me a problem. Then I will shut up.

Cheersy Cheers

Paul

Edited so that it would format correctly - this a continuation of the original post, not my own copmments (Rob)

Re: Class Based Exceptions - Emperors New Clothes

hardyp180 — Fri, 05 Mar 2010 19:03:29 GMT

This is probably my UK reluctance to just say what I mean rather than beating around the bush. I usually live in Australia where people always say what they mean, but I am still English at heart.

The question i implied - but never explicitlly said - is thus.

Can anyone in the world give me a concrete example of why class based exceptions are better than "classic" exceptions beyond saying "because they are" ?

With an example that makes it so obvious that thereafter I will wonder why I even bothered to raise the question.

My guess is nobdy can.

Re: Class Based Exceptions - Emperors New Clothes

Clemenss — Sat, 06 Mar 2010 00:55:03 GMT

Hi,

This is a question for me too. One reason is definitely that class-bases exceptions are standard in most object oriented languages that where object oriented right from the beginning, example is JAVA.

There is just one more really big and quite useful difference:

A class-based exception can be caught directly after it is raised. But if no catch for this exception is found, the logic will go up in the call hierarchy until the search for a matching CATCH is successful. That allows you easily to take specific action for specific exception at any desired level of call hierarchy.

This allows you to create different exceptions for a method and the programmer will decide where to take what action for what kind of exception. This is not possible with classic exceptions. You must react to an exception just where it is raised.

An other advantage (I don't really use) is that you can define your own exception classes. You can use the exception as a container of whatever attributes you like. This is not possible with a classic exception where you can't do more than assign a certain SY-SUBRC to a specific exception when you call the method or function.

What I prefer over this attributes concept is to place a messsage .. INTO dummy statement before raising the exception. Then I have the detailed information in the SY-MSGID SY-MSGTY SY-MSGNO SY-MSGV1 ... SY-MSGV4 variables. Any CATCH may evaluate the SY variables and I have the message in the WHERE-USED list. This is extermely helpful for software maintenance and error management.

Regards,

Clemens

Sorry, no code example given. Just tried to shed light on the concept.

Regards,

Clemens

Re: Class Based Exceptions - Emperors New Clothes

Sandra_Rossi — Sat, 06 Mar 2010 10:38:40 GMT

Nice explanation, Clemens

Re: Class Based Exceptions - Emperors New Clothes

naimesh_patel — Sat, 06 Mar 2010 18:25:51 GMT

Certainly class based exceptions are better than the Old Exceptions. The major advantage of using the new Class based exceptions is you don't need to cascade the exception to your caller like you need to do it in the Old exceptions.

For demo, Create a global class ZCL_CLASS with two methods.

METH_1 Instance Public .. Impl.


  me->meth_2( ).

METH_2 Instance Private

Exception - CX_SY_ZERODIVIDE


  raise exception cx_sy_zerodivide.

In a program, try to catch this exception:


data: lo_obj type ref to zcl_class.
create object lo_obj.
* New Exception
TRY.
    lo_obj->meth_1( ).
  CATCH cx_root.
    write: / 'Class based exception'.
ENDTRY.

Check in debugging, what's going on here and how system caught the exception....

Now, let's try to mimic the same thing using the old exception. In the same class, create two methods:

meth_3 instance public


  me->meth_4( ).

Meth_4 instance private exception NO_DATA_FOUND


  raise no_Data_found( ).

Test program:


* Old Exception
lo_obj->meth_3( EXCEPTIONS no_data_found = 4 ).
IF sy-subrc = 4.
  WRITE: 'No data Found'.
ENDIF.

Try to activate ... It would lead to syntax as Meth_3 doesn't have the exception NO_DATA_FOUND. So, we need to define the exception in the meth_3 and change the implemenation to


  me->meth4( exception no_data_found = 4 ).
  if sy-subrc = 4.
    raise no_data_found.
  endif.

Now the test program would compile and activate.

So, think of the application where you are calling tens of methods which raises these old exceptions in the single method, you need to declare all of the exceptions in the main method (i.e. meth_3). On the other side, if you have used the Class Based exception, you don't need to change the main method. And this is the reason, we are able to catch the catchable exceptions like, CX_SY_ARITHMETIC_OVERFLOW, CX_SY_DYN_CALL_ERROR etc.

From release 700 EhP2, the power of class based exception has been improved by introduction of the RESUME and REPEAT TRY block. http://help.sap.com/abapdocu_70/en/ABENNEWS-71-EXCEPTIONS.htm

I would suggest reading the program flow in case of Old Exception and the new exception: http://help.sap.com/abapdocu_70/en/abenabap_Exceptions.htm

Regards,

Naimesh Patel

Re: Class Based Exceptions - Emperors New Clothes

nomssi — Tue, 22 Jun 2010 15:00:06 GMT

Check this one:

1) Define a checked exception, i.e. in your top include

CLASS lcx_dummy_check INHERITING FROM cx_static_check DEFINITION.

ENDCLASS.

2) Define a routine using this exception

FORM dummy_check USING ps_data RAISING lcx_dummy_check.

Check ps_data here, raise exception in case of error using

RAISE EXCEPTION TYPE lcx_dummy_check.

ENDFORM.

3) Use the routine anywhere in your code, as often as you want.

PERFORM dummy_check.

4) Benefit:

if you do a syntax check, you will get warnings until all lcx_dummy_check exceptions in your code are handled properly.

Now, how do you achieve that with error code?

J.N.N

Re: Class Based Exceptions - Emperors New Clothes

Former Member — Wed, 23 Jun 2010 14:30:06 GMT

I think Clemens, Naimesh and Jacques have answered this pretty well, as far as the benefits of the new exceptions go. But I wanted to respond more specifically to some of Paul's questions. (Rob did mean that his post was actually Paul's, right? I wasn't sure.)

Before I start with the specific questions, I want to introduce three principles I'll refer to repeatedly:

<ol><li>You need to be able to handle exceptions at the most useful place in your code. This means the place where you can either recover from the exception, if possible, or present an intelligent error message to the user, or dump (if the error really is due to a programming problem).</li>

<li>When you write a method, you want its functionality to be adequately encapsulated. This means, you don't want callers to have to care about low-level technical details in the method. It needs to do its job, but it needs to notify callers about what could go wrong inside the method, and tell them if this occurs. It also needs to allow them to react in the most appropriate way to what has gone wrong.</li>

<li>You don't want to gum up your callers' code by making them react to low-level details in your method, or react to events that they know won't occur, provided they use your method in a certain way.</li></ol>

Also, while I'm not going to write any code, I'm going to describe a solution that I'll reference for examples. We have a screen to display information about a purchase order. The user enters the PO number in a screen field, and the program calls a database access class, which connects to a database (for the sake of this argument, I'm going to pretend we're not connecting to ABAP's own database, which handles connections and resources automatically -- in this example, we need to take care of those details ourselves), and retrieves the PO information. The user can then change the information and save.

On to the questions:

<blockquote>u201CIt is often the case however, that instead of handling exceptions, you want to handle only certain ones and pass the rest to the calleru201D. Why? Why wouldnu2019t you want to handle them? An example would be great.</blockquote>

Because you're not at the best place in your code to deal with those exceptions. In the method that accesses the database, let's say we have two possible error situations: either there is a connection problem to the database, or the data is not found. They generate the exceptions CX_CONNECTION_ERROR and CX_NO_DATA_FOUND. If you encounter CX_CONNECTION_ERROR, you might want to try the request again in ten seconds, in case the problem was temporary; or you might want to try a connection to a failover database. In this instance, you're handling the exception. If there was no data found, you have no idea how your caller might want to deal with this. Perhaps it doesn't even expect the data to be there, and is just checking to make sure. You should then propagate the exception to the caller, so that it can handle it properly. You are not handling this exception, because you don't know how to, but your caller probably does. The principle here is: deal with the exceptions you know how to deal with. If you don't know how to deal with an exception, and you have a reasonable belief that the caller does, let it do so.

<blockquote>u201CThere is no way to group similar errors, like there is with runtime errors u2026. You cannot define your own error groupsu201D. Why would you want to? Again, an example might make sense of this.</blockquote>

Let's say there are actually two possible ways in which the connection to the database might fail. Either the system cannot open the underlying connection, or the user has no authorization to connect. These generate the exceptions CX_SOCKET_ERROR and CX_AUTHORIZATION_ERROR, both of which are subclasses of CX_CONNECTION_ERROR. Let's also say that our database connection method decides not to undertake any efforts to retry the connection to the database. It knows that there has been a connection error, but it has insufficient information to tell the user this in a way that is intelligible. (The user wants a message saying that the purchase order could not be retrieved, and why -- not just a message saying that the database connection failed. But the database connection method doesn't know the user scenario in which it is being called.) Therefore, it needs to propagate the exception up to its caller so that it can handle it intelligently. The connection method doesn't care whether an underlying connection error or an authorization error occurred, though. It just had to declare that it raises CX_CONNECTION_ERROR. When this propagated error reaches the caller, it can check to see whether it was actually a CX_SOCKET_ERROR or a CX_AUTHORIZATION_ERROR, to display the correct message to the user, notify a network administrator that a socket error has occurred, and so on. The connection method doesn't care why it couldn't connect, so it can deal with the exception generically. But the caller can take different actions depending upon precisely which error occurred.

If you're the caller, and you know you can't recover from any errors in the connection method, you might even choose to catch CX_ROOT and deal with that. The point is that the system allows you to classify and handle errors hierarchically, instead of at an individual level.

<blockquote>u201CThere is no additional information accompanying the exceptionu2026..u201D u2013 once again, what could this be used for?</blockquote>

Let's say the connection method (or some underlying method) encounters an authorization problem when connecting to the database, and needs to raise CX_AUTHORIZATION_ERROR. It's going to let its caller handle this intelligently, but it wants to give the caller as much information as possible to respond appropriately. It might put more information about the missing authorization into an attribute of CX_AUTHORIZATION_ERROR, so that the system could tell the user precisely which authorization was missing.

Or, for a more business-oriented example, if we have another system for bulk processing of purchase orders, and something goes wrong in a low-level method, the method might want to inform its callers about which purchase order produced an error, so that the method could send a notification to the person responsible for that particular order. The purchase order number might then be stored in an attribute of the exception that is raised, to be dealt with at the correct place in the call chain.

<blockquote>u201CWithin the CLEANUP clause, the system can, for example, restore an object to a consistent state or release external resourcesu201D. What do they mean by this? I have no idea. Yet again, an example would be good.</blockquote>

CLEANUP seems to be an approximation of Java's finally block. In Java, it's almost always used for closing communication channels and database connections if an error occurs. Let's say something goes wrong in the method to write PO information to the database. If the write had succeeded, we would have committed our changes to the database. If the write fails, we want to rollback our changes. But either way, we want to close the connection to the database. (Again, I'm writing here on the assumption that resource handling must be performed by the programmer. This is not true of ABAP databases, but is true of other resources in the language.) We'd then put the database close in the CLEANUP statement -- it must be performed even if execution terminates because of an exception to restore a consistent state. Of course, there are other ways you could have done this without class-based exceptions: CLEANUP just makes your code a little more expressive.

<blockquote>The article manage to ALMOST explain when to use the three types of exceptions u2013 based on CX_STATIC_CHECK, CX_DYNAMIC_CHECK and CX_NO_CHECK ... but once again examples are needed over and above division by zero.</blockquote>

This relates to third principle I established at the top. You want to give your callers a clear interface of what could go wrong in your method. Some of these things have a high probability of occurring in normal execution, and can potentially be handled by the caller. You might want to ensure that these are handled properly, and then you'd use CX_STATIC_CHECK. For instance, CX_NO_DATA_FOUND would be a good candidate for static checking, as there's a high probability that the ID the caller is looking for will not be in the database, and that needs to be dealt with. CX_CONNECTION_ERROR might be a good candidate for CX_DYNAMIC_CHECK -- a database connection error should rarely occur, and your caller might not be prepared to handle it. Therefore, it shouldn't be forced to. If you did force it, it would clutter up the code in the caller unnecessarily. To be honest, I don't really get CX_NO_CHECK. The documentation repeatedly mentions resource bottlenecks. A lot of my understanding of this concept comes from comparison with Java, which uses a very similar exception mechanism to this. Java has java.lang.Exception (which is like CX_STATIC_CHECK) and java.lang.RuntimeException (which is like CX_DYNAMIC_CHECK), but nothing really like CX_NO_CHECK. I assume, though, that CX_NO_CHECK is comparable to java.lang.Error, which is never really subclassed by developers, and relates to extremely low-level problems in the Runtime Environment -- like, indeed, OutOfMemoryError. These should never be caught, and I guess that makes then a sensible analogue for CX_NO_CHECK.

<blockquote>Give me just one code example</blockquote>

If you still need a code example, I can construct one. Any code example that really shows the utility of this functionality is bound to be complicated and long, which is why I think the ones that have been provided have only dealt with part of your question.

As a final aside, on the SAP Professional Journal. I know it has "Professional Journal" at the end, but it's not The Lancet, and doesn't have to try to write like it is. A lot of the articles could be written with half the length, half the academic circumlocution, and twice the clarity. And nobody would take them less seriously.