Stefan, please file the business case that allowing unmatched block labels are
error prone for human readers.
Then, regardless of whether it is handled as and “enhancement request” or as a
“deficiency removal” it will have a chance for action.
I would offer the slight enhancement to the enhancement that this be handled as
a warning by default, lest we cause apparently correctly (or at least
unnoticed) running code that has textual deficiencies to continue as they are.
I *suspect* the modern culture of unit testing by getting through the compiler
has created a sufficient mass of such code to justify being wary in unleashing
the enhancement.
Thanks Bryn. Thanks Toon.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Michael D O'Shea/Woodward Informatics Ltd
Sent: Monday, March 19, 2018 4:55 AM
To: knecht.stefan@xxxxxxxxx
Cc: Toon Koppelaars; oracle-l-freelists
Subject: Aw: PL/SQL Interpreter oddity - bug or "expected"?
Am 19.03.2018 um 07:57 schrieb Stefan Knecht <knecht.stefan@xxxxxxxxx>:
So to summarize, I still feel that the behavior isn't what
I'd expect. Regardless of what "loop" is underneath the covers,
it has a special meaning, and that meaning is entirely obliterated
by the compiler treating it as a mere label.
Please check out this enhancement request. I filed it on 31-Mar-2008.
ER 6931048 - Implement new warning when block label doesn't match “end ... ;”