Is there a way to identify mismatched number of parameters passed to routine before runtime? - Progress Community

Loading

Skip to Main Content

Is there a way to identify mismatched number of parameters passed to routine before runtime?

Is there a way to identify mismatched number of parameters passed to routine at compile, to avoid "Mismatched number of parameters passed to routine (3234)" at runtime ?

Jan 27, 2016
Knowledge

Title

Is there a way to identify mismatched number of parameters passed to routine before runtime?

URL Name

000033320

Article Number

000153420

Environment

Product: OpenEdge Version: All supported versions OS: All Supported Operating Systems

Question/Problem Description

Is there a way to identify mismatched number of parameters passed to routine before runtime?
Why is error "Mismatched number of parameters passed to routine <name>. (3234)" not identified during compilation?

Steps to Reproduce

Clarifying Information

Error 3234 is displayed in runtime when missing parameters are passed to a routine

Error Message

Mismatched number of parameters passed to routine <name>. (3234)

Defect Number

Enhancement Number

Cause

The OpenEdge compiler is a single unit compiler and can’t check for changes on procedures definition.

After you compile a procedure, the RUN statement does not recompile it. If you RUN a procedure multiple times within a session, changing the procedure between runs, you must manually recompile the procedure each time. Otherwise, the procedure’s last r-code, which persists for a session, is found and the procedure is not automatically recompiled.

Resolution

It is an expected behavior in OpenEdge compiler. Using the XREF option while compiling might reduce the task to look in each code calling a procedure.

Unfortunately there isn’t a mechanism to check for the definition of the parameters in a procedure.

The XREF option in the COMPILE statement won’t highlight the missing parameter but will give the line only in external procedures where the RUN statement is used for that called procedure, helping you to check for parameters in those calls.

For example:

Having procedure1 where it has RUN statements and procedure2 where it has the definition of the procedure, the XREF option will report all the calls in procedure1 as follows:

C:\OpenEdge\WRK102b\procedure1.p C:\OpenEdge\WRK102b\procedure1.p 6 RUN genderbender
C:\OpenEdge\WRK102b\procedure1.p C:\OpenEdge\WRK102b\procedure1.p 11 RUN genderbender
C:\OpenEdge\WRK102b\procedure1.p C:\OpenEdge\WRK102b\procedure1.p 16 RUN genderbender
C:\OpenEdge\WRK102b\procedure1.p C:\OpenEdge\WRK102b\procedure1.p 21 RUN genderbender
C:\OpenEdge\WRK102b\procedure1.p C:\OpenEdge\WRK102b\procedure1.p 26 RUN genderbender

In some way that could point at least the lines to check if the parameters are not missing. In an internal procedure it should be done manually since XREF just reports the definition of the procedure.

Workaround

Notes

This applies only to procedural-based code.
Object-oriented constructs (ie. Classes and Interfaces) will use a multi-pass compiler to be able to enforce strong-typing, and those will detect signature mismatches at compile-time.

References to other documentation:
OpenEdge Development:ABL Reference, "ABL Reference, COMPILE statement"

Keyword Phrase

Last Modified Date

1/27/2016 3:07 PM

OpenEdge DeploymentOpenEdge ArchitectureOpenEdge DevelopmentOpenEdge General DiscussionsOpenEdge Pro2OpenEdge RDBMS

Drop Files

Upload FilesOr drop files

Disclaimer

The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.

Loading

Is there a way to identify mismatched number of parameters passed to routine before runtime? - Progress Community