Mike Pokraka

Hmm, I tend towards the opposite and prefer exceptions over messages. One simple issue blows the whole BAPIRET idea out of the water, and that is that a return value...

Also, regarding exception classes, I tend to be quite liberal with them. It only takes two lines of code to define a subclass that will make your technical errors more...

If it _really_ shouldn't happen (e.g. only through programmer error), then I'd even go as far as `assert` There's another related (anti?)pattern: ```abap if . do stuff. do things. ......

Thanks for your comments. I had a hard time deciding the "feature" term myself so I thought I'd put it out there for comments. The reason to call it "test...

> * [Don't mix test code with production code](https://8thlight.com/blog/dariusz-pasciak/2014/12/19/dont-mix-test-code-with-production-code.html) I like this wording, and good blog too.

Yes, I do think it's harshly formulated, it suggests that locals are all but verboten. "Take care when using local classes" is an approach I'd be comfortable with. Your explanation...

Sorry I didn't even notice I closed it by accident.

Hi Florian, Overall very well explained. However I feel that this bit is too subjective: _Orientation, navigation, and debugging in very long local class includes is tedious and annoying._ I...

I like a good discussion :-) But I still don't agree. Your "at the moment" argument is one that can go both ways. Have a look at the idea behind...

Hmm, are you not mixing ease of modification with ease of re-use? A local class is certainly easier to modify, as you don't have the constraint of a public API...