In this issue:
ABAP Exceptions: Unknown Thus Unloved
Get To The Con!
Everything You Can Do I Can Do Better: ERP Edition
Back To Bimodal
Outsmart the AI
Cinquain In The Membrane
ABAP Exceptions: Unknown Thus Unloved
Watching the video You’re Doing Exceptions Wrong made me realize that in the ABAP world, we’re not just doing it wrong - sometimes we’re not doing it at all.
I was already familiar with the concept of exceptions before working with ABAP. But to be honest, I didn’t fully embrace class-based exceptions beyond the basic TRY/CATCH
. The last ABAP book written by the legendary Thomas&Rich duo did cover exception classes. My first reaction to those examples was: “WTF is this?” And that wasn’t the authors’ fault - it was more about SAP’s vision how the exception classes should be used. A rigid implementation, specific predefined exceptions, messages embedded in the exception class, and confusing interfaces didn’t help to drive the adoption.
Years later, I stumbled upon a much simpler and more flexible implementation in one of the open-source ABAP projects. That was my “wait, we can do that?!” moment. It really helped me level up my exception game. Here are some practical tips that might help others in the same boat:
It’s important to understand what is and isn’t an exception. Let’s say a method is supposed to return some data, but that data might not exist. In that case, there’s no need to raise an exception - the method can simply return nothing. The calling method can then decide how to handle it. In general, an exception is something unexpected or something that requires special handling.
I still haven’t found any truly good posts about exception classes, which is part of the problem. For general information about exceptions, I recommend this post. SAP also provides a large number of examples here (sadly, more of the same confusing variety). And I’d suggest this exception class implementation in abapGit for a more approachable alternative.
Also, exceptions don’t have to be caught immediately. It’s perfectly fine to let them propagate “up the chain”. This is one of the main advantages of methods over subroutines. You can even catch one exception and immediately raise a different one. Mind-blowing stuff.
Exception classes are still classes, which means they can carry a lot of additional information by reference - super helpful for troubleshooting. Need to surface a BAPI error from a few levels deep? An exception class is your friend.
A notable point from the video: “Exceptions are observability.” They give useful context and make your code friendlier to other developers. Don’t get stuck in sy-subrc
hell, use them! JP
Get To The Con!

I've said it before and I'll say it again: SAPUI5 is the best piece of technology to come out of SAP since HANA. I think history has shown that it was the right call to make a toolkit tailored to the enormous ERP use case. The very beginning was a spartan, not-very-well-performing glance toward a useful framework…and then it evolved and improved with every release. It came with a design system, spawned a super-useful quick time-to-production low-code framework, and made itself known across the whole SAP product portfolio.
It is therefore right with the universe that there's a conference dedicated to UI5. It's amazing that this conference will have its 10th iteration this year. UI5 is a success as a community as well as a technology! (I'm glad that this particular community has grown roots outside of the mainline SAP community site, which has felt a little off lately.) If you're in St. Leon-Rot in July…you better be attending. PM
Everything You Can Do I Can Do Better: ERP Edition
A few months ago, I foolishly heroically volunteered to deliver a presentation “What on Earth is ERP?” at my kid’s high school. Now, I’ve given many talks on SAP subjects before, but explaining this to teenagers was an uncharted territory. The trial run with the focus group aka my 15-year-old son (“uh… mom, what’s an invoice?”) illuminated the need for a radical content recalibration.
I think about that experience whenever I encounter social media posts where grown-ass adults exhibit an ERP IQ roughly equivalent to that of an average high schooler. “OMG, SAP is so old and bloated! I bet one or two developers (well, three tops) could just vibe-code a better system, with AI and automation and s*t.” OK, maybe I’m exaggerating slightly. But still, check out this guy reinventing Joule or this visionary “decoupling for Agility […] with Agentic AI-driven microservices.” There are more where these came from.
It's entertaining to fantasize about creating “a better SAP, with Blackjack and hookers.” But, as with most flights of fancy, these ideas conveniently skip over the boring realities. For the teenagers, I summarized “why do we need ERP systems?” thusly: robust functionality (ERP <> “QuickBooks on steroids”), scale, integration, reliability, compliance. If your “dream product” does not tick all these boxes, it’s not even in the same league.
And let’s not forget the narrative arc of so many wannabe disruptors: slay the dragon, become the dragon. If you could actually pull off “a better S/4HANA”, you’d just become “new SAP” within two fiscal quarters. Oh, the irony. JP
Back To Bimodal
A few issues ago, I wrote about the bimodal distribution of developers, with respect to their feelings on AI as code help. I called the two groups "AI Code Haters" and those who "Drink the AI Code Kool-Aid". Related, Joule for ABAP hit the newsstands in February. There's a nice blog with a feature breakdown, check it out.
I've been thinking about what I've seen of the Joule for developers, ABAP AI capabilities, and I'm revising my bimodal nomenclature. I see Joule laying out specific flows and scenarios, with defined ways to accomplish them, and it got me thinking. Maybe the key distinction between the two modes is expectations.
Here are the two expectation modes as I see them:
AI as Collaborator (closely aligns with the AI Kool-Aid drinkers)
See Joule and thinks: "These features seem oddly constrained and limited."
Wonders why users are prescribed narrow, limited features.
Wants the AI to figure things out along with them. Wants the AI to make little suggestions, go to weird places.
Sees the chat input as an invitation to collaboration: "Vibe code with me."
AI as Tool (closely aligns with AI Code Haters)
See Joule and think: "This clearly lays out features that I can check."
Wonders why users don't have a manual for using Claude/ChatGPT/etc.
Wants the AI to do things dependably, reliably. Wants a hammer that pounds nails, not that offers suggestions on picture placement.
Sees the chat input as a command line: "Show me the command manual."
Joule's design doesn't really appeal to me - but I am starting to understand how it might to others. PM
Outsmart the AI
As the name suggests, the recent article Design Smarter: Future-Proof Your UX Career in the Age of AI is aimed at UX designers contemplating their career paths. But even if we replace "UX designers" with "software developers" - or many other professions - Pavel Bukengolts's advice still holds strong.
While the AI takeover may not be as imminent as some fear—or eagerly anticipate, depending on one's place in the corporate hierarchy - our jobs are undeniably evolving. And Pavel offers simple but solid guidance: “Stay curious. Stay sharp. Keep asking better questions.” From my experience, the latter is what separates great developers from mediocre ones. Anyone can learn a programming language or how to use a tool, but empathy and attention to detail are much harder to come by. JP
Cinquain In The Membrane
Cinquain is a form of poetry that I think lends itself to the especially wordy ABAP keyword list. (It’s not the only form - see past excursions into haiku.)
In that spirit, I collaborated with Claude to come up with some ABAP cinquains. The rule: except for the title, only use ABAP keywords. At least one of the below cinquains is entirely AI-generated, and at least one of the below is entirely human-generated. PM
"Beyond" TRY FIRST STEP FAIL BREAK FORWARD RISK CATCH CHANGE LEVEL UP "Refresh" GREEN NEW DAYLIGHT BLUE YELLOW PINK CHANGE ENVIRONMENT CLEAR DISPLAY NEW "Rejoin" LEFTSPACE ONLY DISTANCE CREATE COMMON MEMORY DISCONNECT DIVISION BOUNDARIES NO-GAP
Watch the corresponding Nerdletter Talk on our YouTube channel for saucy comments and bonus content that didn’t make the cut.
Don’t miss our exciting new Show&Tell episode SAP Analytics Cloud Showcase with Daniel Leal. You’ll love the financial statement example Daniel picked for the demo!
This newsletter is written by humans. Who run mostly on coffee. Support the Boringverse by buying us a cup or two. Well, there are two of us, so two cups really should be minimum. Anyways. Thanks for your readership and support!
Oh no, please not "TRIAL" and "ERROR".
After TRY and CATCH was introduced the "Unknown System Error" prompt to the user became commonplace . A calls B calls C. C throws a message, developer of B was needed to finish his increment/ was lazy/ couldn't care less and is not handling the error, and developer of A never foresaw the error because he never ever heard about C. Now he just pushes the whole mess back to the user.
Who is responsible? No one knows, somewhere in the code mess someone threw an error, and no one cared about handling it. That's all we know.
Errors/Exception should be handled locally where they occur. Not praying that someone should care about it. No one knows where the code is which handles the error.
Spaghetti coding.