Rule request - Blocks that are not affected by BLOCK-LEVEL ON ERROR UNDO, THROW need error handling

[movedoa]

There are blocks that are not effected by BLOCK-LEVEL ON ERROR UNDO, THROW.
https://docs.progress.com/bundle/openedge-abl-error-handling-122/page/BLOCK-LEVEL-ON-ERROR-UNDO-THROW-statement.html

A rule that checks if every DO and DO WHILE block has an error handling directive and every Destructor and Event Method (every method that is subscribed to something) has a catch would help to deal with unexpected errors in the code.

The ABL Events are a bit of a special case since if the Publish comes from the AVM, the error is thrown to the publish, which is fine.
But if you subscribe to anything in the .NET runtime (a winforms control for example), the error is still raised in the normal way, the only way to handle that is a catch in the subscribed method.
https://docs.progress.com/bundle/openedge-oo-abl-develop-applications/page/Raise-errors-within-a-class-event-handler.html

A classic example of this problem is a session that runs in batch mode and has some error in, lets say, the destructor.
Without a catch ther error message is piped to stdout (maybe a terminal window, maybe a log file) but all you get ist "Lead attributes in a chained-attribute expression" without a stack or any additional infos.

This is especially fun with bugs that only appear once a month under unknown conditions.

[movedoa]

Got bitten by a variation of this again today.
The error message we saw was a subsequent error in a completely different source file because a DO ON ERROR UNDO, LEAVE block without at CATCH statement swallowed the original error.

[gquerret]

While reporting every DO and DO WHILE is possible, the number of FP (or cases where you don't know what to do with the error) would be way too high. Destructors and events are more reasonable targets.

[movedoa]

I understand that the DO blocks would create a lot of issues depending on coding style but for us it would still be very helpful i think.
A DO block without a UNDO, THROW should always have a CATCH in our code base to detect unexpected errors or to at least explicitely ignore the error.
Since we compile with -undothrow 2, this would give us realiable stack traces even in batch mode and would save us a lot of detective work to hunt down issues.

So maybe this could be an opt in option in the rule? :)
Unless there is some technical reason this can't be checked reliably?