Why is it not allowed to declare an exception that inherits from CX_NO_CHECK?

[KjetilKilhavn]

I find it useful to let e.g. exceptions for authorization check failures inherit from CX_NO_CHECK. That way they can be handled at a high level without having to be declared in every method.

However, that does not mean I don't want to inform callers that a particular method may raise that exception. However, when I try to add a RAISING clause I get an error message, apparently a warning was not sufficient, that the exception does not inherit from CX_STATIC_CHECK or CX_DYNAMIC_CHECK.

It seems someone decided that the best should be the enemy of the good in this respect: If you don't accept being forced to declare or handle it we will not even allowed you to declare it as a helpful hint to callers that the exception can be raised.

[retired_member]

Please read the documentation and the guidelines carefully.

https://help.sap.com/http.svc/rc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abenexception_cate...

There is no need for a RAISING clause for subclasses of cx_no_check because those are propagated implicitly. That's the main purpose of those. For mere documentation purposes use the method documentation or ABAP Doc. Otherwise, use the recommended exception categories.

[pokrakam]

Although I haven't personally had the need for it, I'm with Kjetil on this. Documentation is all good and well, but when I hit F2 on a method in code, it's almost always to review the signature.

So from a method author's point of view I'd like to hilight the exception to my consumers, even if I don't care whether they handle it or let it slide up the call stack. The documentation is clear, but I see no reason to ban declaration of an ignorable exception.

[KjetilKilhavn]

There are many things in this world for which there is no need - we don't necessarily make them illegal just because they are not needed 😉

I think C++ has the right concept here, where all exceptions are propagated unless they are handled. Intermediate methods don't need to know or care about them unless they want to, only the thrower and the catcher has to care.

I see the point of documentation and the "contract" of the method signature, but the checked exceptions require additional work, while allowing declaration of an unchecked exception would - as Mike points out - let developers see which exceptions could occur and then decide whether to handle them in the current method or higher in the call chain.

However, I also realize that implementing my suggestion would require additional work from your ABAP developers, who are already busy implementing great new features like the OFFSET addition to SELECT (thumbs up). So it's either more work for you or for the rest of us. I vote for you 🙂