[Stackoverflow] [Progress OpenEdge ABL] Pros and cons using OOABL for 12+ version

[Lucas Bicalho]

I read the PROS and CONS of using OO for Progress OpenEdge in 10.2b version.

I would like to redo the same question, but focusing on the new 12+ version.

Specifically, has anything changed from what was pointed out by @Abe Voelker from 10.2b to 12+ versions?

• Class hierarchies are limited; you can’t create inherited (sub-) interfaces in 10.2B (I think this was going to be added in 11). Older versions of OpenEdge have other limitations like lack of abstract classes. This limits your ability to create clean OO design and will hurt you when you start building non-trivial things.
• Error handling sucks - CATCH/THROW doesn’t let you throw your custom errors and force callers to catch them. Backwards compatibility prevents this from evolving further so I doubt it will ever improve.
• Object memory footprint is large, and there are no AVM debugging tools to track down why (gotta love these closed systems!)
• Garbage collection wasn’t existent ‘til 10.2A, and still has some bugs even in 11 (see official OE forum for some examples)
• Network programming (with sockets) is a PITA - you have to run a separate persistent procedure to manage the socket. I think evented programming in OOABL was a PITA in general; I remember getting a lot of errors about “windowed environments” or something to that effect when trying to use them. PUBLISH/SUBSCRIBE didn’t work either, if memory serves.
• Depending on your environment, code reviews may be difficult as most Progress developers don’t do OOABL so may not understand your code

And by @firhang

Only one thing - "Error handling sucks" - it sucks, but not because you can not make your own error-classes a catch them in caller block - that works, I'm using that. What sucks is that mix from old NO-ERROR / ERROR-HANDLE option and Progress.Lang.Error / CATCH block and ROUTINE-LEVEL ON ERROR UNDO, THROW. That is a big problem, when exists no convention in team, which errorhandling and how will be used.

Continue reading...