Information processing device, information processing method, and program

Abstract

When a program is executed using lazy evaluation, exception handling should be performed in the same way as in sequential execution. [Solution] The information processing device includes a variable detection means that performs a process to detect a variable to be evaluated at the current position from the current position if the device determines that the entire exception handling block is located on the side of the program execution progress relative to the current position in the program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, and an evaluation means that evaluates the variable if the variable to be evaluated is detected.

Description

[Technical Field]

[0001] The present disclosure relates to an information processing apparatus, an information processing method, and a program. [Background Art]

[0002] Exception handling may be performed during execution of a program (see, for example, Patent Document 1). [Prior Art Literature] [Patent Literature]

[0003] [Patent Document 1] Japanese National Publication of International Patent Application No. 2008-537245 [Summary of the Invention] [Problem to be Solved by the Invention]

[0004] One of the methods for executing a program is Lazy Evaluation. If, when a program is executed by lazy evaluation, exception handling can be performed in the same manner as in the case of sequential execution, there is no need for a user to be aware of exception handling specific to lazy evaluation when preparing a source program, and in this respect, the burden on the user can be reduced.

[0005] An example of an object of the present disclosure is to provide an information processing apparatus, an information processing method, and a program that can solve the above-described problem. [Means for Solving the Problem]

[0006] According to a first aspect of this disclosure, the information processing device includes a variable detection means that performs a process to detect a variable to be evaluated at the current position from the current position if it is determined that the entire exception handling block is located on the side of the program execution direction relative to the current position in the program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block; and an evaluation means that evaluates the variable if a variable to be evaluated is detected.

[0007] According to a second aspect of this disclosure, the information processing method includes, when the computer determines that the entire exception handling block is located in the direction of program execution from the current position in program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, the computer performs a process to detect a variable to be evaluated at the current position from the current position, and if a variable to be evaluated is detected, the computer evaluates that variable.

[0008] According to a third aspect of this disclosure, the program causes the computer to perform the following actions if it determines that the entire exception handling block is located in the direction of program execution from the current position in the program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block: to detect the variable to be evaluated at the current position from the current position; and to evaluate the variable if the variable to be evaluated is detected. [Effects of the Invention]

[0009] According to the embodiments of this disclosure, when a program is executed using lazy evaluation, exception handling can be performed in the same way as in the case of sequential execution. [Brief explanation of the drawing]

[0010] [Figure 1] This figure shows an example of the configuration of an information processing device according to at least one embodiment. [Figure 2]This figure shows the first example of a source program that includes exception handling. [Figure 3] This figure shows a second example of a source program that includes exception handling. [Figure 4] This figure shows examples of data input and output in each part of the front-end unit according to at least one embodiment. [Figure 5] This figure shows a third example of a source program that includes exception handling. [Figure 6] This figure shows a fourth example of a source program that includes exception handling. [Figure 7] This figure shows a first example of the configuration of a bytecode inspection unit according to at least one embodiment. [Figure 8] This figure shows a fifth example of a source program that includes exception handling. [Figure 9] This figure shows a second example of the configuration of a bytecode inspection unit according to at least one embodiment. [Figure 10] This figure shows a sixth example of a source program that includes exception handling. [Figure 11] This figure shows a third example of the configuration of a bytecode inspection unit according to at least one embodiment. [Figure 12] This figure shows the seventh example of a source program that includes exception handling. [Figure 13] This figure shows the eighth example of a source program that includes exception handling. [Figure 14] This figure shows the ninth example of a source program that includes exception handling. [Figure 15] This figure shows the tenth example of a source program that includes exception handling. [Figure 16] This figure shows a fourth example of the configuration of a bytecode inspection unit according to at least one embodiment. [Figure 17] This figure shows the eleventh example of a source program that includes exception handling. [Figure 18] This figure shows a fifth example of the configuration of a bytecode inspection unit according to at least one embodiment. [Figure 19]FIG. 12 is a diagram showing a twelfth example of a source program including exception processing. [Figure 20] FIG. 6 is a diagram showing a sixth example of the configuration of a byte code inspection unit according to at least one embodiment. [Figure 21] FIG. 7 is a diagram showing a seventh example of the configuration of a byte code inspection unit according to at least one embodiment. [Figure 22] FIG. 9 is a diagram showing an example of a processing procedure for determining whether or not to perform preventive evaluation at a current position by an information processing apparatus according to at least one embodiment. [Figure 23] FIG. 12 is a diagram showing an example of a processing procedure for determining whether or not to perform preventive evaluation at a current position in order to prevent false detection by a byte code inspection unit according to at least one embodiment. [Figure 24] FIG. 15 is a diagram showing an example of a processing procedure for determining whether or not to perform preventive evaluation at a current position in order to prevent missed detection by a byte code inspection unit according to at least one embodiment. [Figure 25] FIG. 13 is a diagram showing a thirteenth example of a source program including exception processing. [Figure 26] FIG. 21 is a diagram showing an example of an assembly language-style display of a byte code into which a source program has been converted. [Figure 27] FIG. 24 is a diagram showing an example of the configuration of an information processing apparatus according to at least one embodiment. [Figure 28] FIG. 27 is a diagram showing an example of processing in an information processing method according to at least one embodiment. [Figure 29] FIG. 30 is a diagram showing an example of the configuration of a computer according to at least one embodiment. DESCRIPTION OF EMBODIMENTS

[0011] Hereinafter, embodiments will be described with reference to the drawings.

[0012] <First Embodiment> Figure 1 shows an example of the configuration of an information processing device according to at least one embodiment. In the configuration shown in Figure 1, the information processing device 100 includes a communication unit 110, a display unit 120, an operation input unit 130, a storage unit 180, and a processing unit 190. The processing unit 190 includes a front-end unit 210, a middleware unit 220, and a back-end unit 230. The front-end unit 210 includes a variable operation start unit 211, an intermediate representation generation unit 212, a byte code acquisition unit 213, a byte code inspection unit 214, an evaluation unit 215, and a variable operation end unit 216.

[0013] The information processing device 100 executes the source program using lazy evaluation. In lazy evaluation, the information processing device 100 partially converts the source program into an intermediate representation (IR). Then, when executing an instruction that requires the value of a variable, such as a "print" instruction, the information processing device 100 executes the intermediate representation to calculate the variable value. The process of determining the value of a variable is also called evaluating that variable. For example, the information processing device 100 generates an intermediate representation during runtime compilation of the source program and performs lazy evaluation of the generated intermediate representation. The variables evaluated by the information processing device 100 are not limited to any particular type of variable. For example, the information processing device 100 may evaluate data frame variables (variables in matrix form), but is not limited to this.

[0014] The source program referred to here is the program that the information processing device 100 is intended to execute. The source program may, but is not limited to, a user program (a program created by a user). Converting a source program into an intermediate representation is also referred to as generating an intermediate representation. An intermediate representation can be understood as a program expressed in the form of an intermediate representation.

[0015] Furthermore, when the information processing device 100 executes the source program using delayed evaluation, it adjusts the timing of variable evaluation so that exception handling is performed in the same way as in the case of sequential execution. In the following, exceptions will also be referred to as errors, and the name of an exception (the type of exception) will be referred to as the error name. Furthermore, the handling of exceptions will be referred to as error handling.

[0016] Figure 2 shows a first example of a source program that includes exception handling. In the example in Figure 2, "df" indicates the variable name, and "df = …………" indicates that a value is assigned to the variable df. "df = df. …………" indicates that the value of variable df is updated by assigning a value calculated by referencing variable df back to variable df. Furthermore, part B11 of the source program in Figure 2 corresponds to an example of an exception handling block. An exception handling block indicates the scope of exception detection and the processing to be performed in relation to the exception detection. Part B11 includes parts B12 and B13.

[0017] Section B12 is the scope of exception detection within the exception handling block of section B11. The scope of exception detection within the exception handling block is also referred to as the exception detection target section or the try block. Section 13 shows the actions to be taken when an exception is detected in Section B12. The section that shows the actions to be taken when an exception is detected is also called the exception handling section or the except block. Additionally, position P11 indicates the location of the assignment statement "df = df.…………". Position P12 indicates the location of the print statement "print(df)".

[0018] Now, let's consider the case where the computer executes the source program in Figure 2 sequentially. In this case, at position P11, the computer executes the assignment statement "df = df.…………". Specifically, the computer calculates the value of the variable df based on the right-hand side of the assignment statement and assigns the obtained value to the variable df. Executing the assignment statement "df = df.…………" is an example of evaluating the variable df. If an exception with the error name shown in section B13 occurs during the evaluation of the variable df at position P11, the computer performs the error handling shown in section B13. In the following, the occurrence of an exception with the error name shown in the except block will also be referred to simply as "an exception occurring."

[0019] On the other hand, if the computer executes the source program in Figure 2 using lazy evaluation and does not adjust the timing of the evaluation, at position P11, instead of executing the assignment statement "df = df.…………", it generates an intermediate representation of the assignment statement "df = df.…………". Then, when the computer executes the print statement "print(df)" at position P12, it uses the intermediate representation generated at position P11 to obtain the value of the variable df.

[0020] In this case, the computer will evaluate the variable df, which is shown at position P11, at position P12. Even if an exception occurs at position P12 due to the evaluation of variable df, the computer will not execute the error handling shown in section B13 because it is outside the try block (part B12).

[0021] Thus, the handling of exceptions may differ depending on whether the example in Figure 2 is executed sequentially or with lazy evaluation. Evaluating the variables shown in the try block outside the try block (executing them after the exception handling block has finished) is also called overlooking an exception.

[0022] In response to this, if the information processing device 100 determines that an oversight may occur, it prevents the oversight by executing the operation on the variable at the location where the operation appears. Here, an operation on a variable refers to executing all the intermediate representations that have been generated for that variable up to that point and obtaining a specific processing result. An assignment statement that assigns a value to a variable is an example of an operation on that variable. In the example shown in Figure 2, the information processing device 100 generates an intermediate representation of the assignment statement "df = df.…………" at position P11 and executes the generated intermediate representation. As a result, if an exception occurs during the execution of the assignment statement "df = df.…………", the information processing device 100 performs the error handling shown in section B13. In addition, the direction of execution of the source program is referred to as "rear," and the opposite direction is referred to as "front."

[0023] Figure 3 shows a second example of a source program that includes exception handling. In the example in Figure 3, "df1" and "df2" both represent variable names. "df1 = …………" indicates that a value is assigned to the variable df1. "df2 = df1.…………" indicates that the value calculated by referencing the variable df1 is assigned to the variable df2.

[0024] Furthermore, part B21 of the source program in Figure 3 corresponds to an example of an exception handling block. Part B21 includes parts B22 and B23. Part B22 is the try block in the exception handling block of part B21. Section B23 is the except block in the exception handling block of section B21. Section B23 shows the actions that should be taken when an exception is detected in section B22. Furthermore, position P21 indicates the position of the assignment statement "df1 = …………". Position P22 indicates the position of the assignment statement "df2 = df1.…………".

[0025] Now, let's consider the case where the computer executes the source program in Figure 3 sequentially. In this case, at position P21, the computer executes the assignment statement "df1 = …………". Executing the assignment statement "df1 = …………" is an example of evaluating the variable df1. If an exception occurs during the evaluation of the variable df1 at position P21, the computer does not perform the error handling shown in section B23 because it is outside the RTY block (section B22).

[0026] On the other hand, if the computer executes the source program in Figure 3 using lazy evaluation and does not adjust the timing of the evaluation, at position P21, instead of executing the assignment statement "df1 = …………", it generates an intermediate representation indicating the execution of the assignment statement "df1 = …………". Then, when the computer executes the assignment "df2 = df1.…………" at position P22, it uses the intermediate representation generated at position P21 to determine the value of variable df1 and then the value of variable df2. Determining the value of variable df1 during the execution of the assignment "df2 = df1.…………" is an example of evaluating variable df1.

[0027] In this case, the computer will evaluate the variable df1, which is indicated at position P21, at position P22. If an exception occurs at position P22 due to the evaluation of variable df1, since it is within a try block (part B22), the computer will execute the error handling shown in part B23.

[0028] Thus, the handling of exceptions may differ depending on whether the example in Figure 3 is executed sequentially or with lazy evaluation. Evaluating variables shown outside the try block (before the try block) within the try block is also called a false positive.

[0029] In response to this, if the information processing device 100 determines that a false detection may occur, it prevents the occurrence of a false detection by executing the operation on the variable at the location where the operation would normally appear. In the example shown in Figure 3, the information processing device 100 generates an intermediate representation of the assignment statement "df1 = …………" at position P21 and executes the generated intermediate representation. As a result, if an exception occurs during the execution of the assignment statement "df1 = …………", the information processing device 100 does not execute the error handling shown in section B23. The evaluation of variables performed to prevent oversights, and the evaluation of variables performed to prevent false positives, are also called preventative evaluations.

[0030] In the configuration shown in Figure 1, the communication unit 110 communicates with other devices. For example, the communication unit 110 may be configured to receive source programs from other devices. Alternatively, the communication unit 110 may be configured to transmit the execution results of the source programs to other devices, such as a user's terminal device.

[0031] The display unit 120 includes a display screen such as an LED (Light Emitting Diode) panel or a liquid crystal panel, and displays various images. For example, the display unit 120 may be configured to display the execution results of a source program. The operation input unit 130 includes, for example, input devices such as a keyboard and a mouse, and accepts user operations. For example, the operation input unit 130 may accept user operations to specify a source program to execute, user operations to specify options for executing the source program, and user operations to instruct the execution of the source program.

[0032] The storage unit 180 stores various types of data. For example, the storage unit 180 may store intermediate representations generated by the information processing device 100 during the delayed evaluation of the source program. The storage unit 180 is configured using the storage devices provided by the information processing device 100. The processing unit 190 controls various parts of the information processing device 100 to perform various processes. The functions of the processing unit 190 are realized when the CPU (Central Processing Unit) of the information processing device 100 reads a program from the storage unit 180 and executes it.

[0033] The front-end unit 210 partially converts the source program into an intermediate representation. Specifically, the front-end unit 210 traverses the source program according to the execution order shown in the source program and generates an intermediate representation for lazy evaluation. Hereafter, the position in the source program that the front-end unit 210 is referencing by traversing the source program (or the code obtained by converting the source program) will also be referred to as the current position.

[0034] Furthermore, the front-end unit 210 decides whether or not to evaluate the variables that appear at the current position as variables to be manipulated, and then evaluates the variables that it has decided to evaluate. Deciding whether or not to evaluate the variables that appear at the current position can be understood as detecting the variables to be evaluated at the current position from the current position. In this sense, detecting variables from the current position means detecting variables from the code (program description) at the current position. The following explanation will describe an example where the front-end unit 210 references the bytecode converted from the source program instead of directly referencing the source program. However, the front-end unit 210 may also directly reference the source program.

[0035] The variable manipulation initiation section 211 functions as an interface from the source program to the intermediate representation. For example, the variable manipulation start unit 211 obtains information about the current position of the source program, such as obtaining information about the variable being manipulated at the current position. The variable manipulation start unit 211 then gives instructions to subsequent functional units. For example, the variable manipulation start unit 211 instructs the intermediate representation generation unit 212 to generate an intermediate representation following the variable being manipulated at its current value. In this way, the variable being manipulated at the current position becomes the target of intermediate representation generation. The variable manipulation start unit 211 also instructs the byte code acquisition unit 213 to acquire byte code based on the current position where the manipulated variable appears.

[0036] The intermediate representation generation unit 212 generates an intermediate representation. Specifically, the intermediate representation generation unit 212 uses the generated intermediate representation to generate an intermediate representation for determining the value of the variable being manipulated at the current position.

[0037] The bytecode acquisition unit 213 acquires the bytecode of the source program. The bytecode inspection unit 214 refers to the bytecode of the source program and decides whether or not to evaluate a variable that appears as an manipulated variable at the current position (the current position in the execution of the source program). The bytecode inspection unit 214 deciding whether or not to evaluate a variable that appears at the current position can be understood as detecting the variable to be evaluated at the current position from the current position. The bytecode inspection unit 214 is an example of a variable detection means.

[0038] The evaluation unit 215 evaluates variables. In particular, the evaluation unit 215 evaluates variables that the bytecode inspection unit 214 has decided to evaluate. The evaluation unit 215 also evaluates variables that appear in instructions that require evaluation, such as print statements. The evaluation unit 215 is an example of an evaluation means.

[0039] The variable manipulation termination section 216 functions as an interface from the intermediate representation side to the source program side. For example, the variable operation termination unit 216 wraps the intermediate representation as a variable on the intermediate representation side, or the data of the specific processing result obtained by evaluating the intermediate representation, in the format of a user program variable and returns it to the source program side.

[0040] The middleware unit 220 performs optimization on the intermediate representation generated by the intermediate representation generation unit 212. The optimizations performed by the middleware unit 220 are not limited to specific ones. For example, the middleware unit 220 may optimize the execution order of the process of deleting columns of data frame variables (variables shown in matrix form), but is not limited to this.

[0041] The backend unit 230 performs the intermediate representation. The functions of the backend unit 230 may be executed using hardware separate from the hardware that executes the functions of the frontend unit 210. For example, the information processing device 100 may be equipped with an accelerator such as a GPU (Graphics Processing Unit) in addition to a CPU, and the functions of the processing unit 190 may be executed using both the CPU and the accelerator. Furthermore, the functions of the front-end unit 210 may be executed using the CPU, and the functions of the back-end unit 230 may be executed using an accelerator such as a GPU.

[0042] Figure 4 shows examples of data input and output in each part of the front-end unit 210. In the example shown in Figure 4, the variable manipulation start unit 211 obtains information about the current position of the source program, including information about the variable being manipulated at the current position. The variable manipulation start unit 211 then outputs an instruction to the intermediate representation generation unit 212 to generate an intermediate representation following the variable being manipulated at the current value, along with information indicating the parameters for that operation. The variable manipulation start unit 211 also instructs the byte code acquisition unit 213 to acquire byte code based on the current position where the variable being manipulated appears.

[0043] The intermediate representation generation unit 212 generates an intermediate representation indicating the instruction at the current position of program execution, based on the information output from the variable operation start unit 211, which indicates the operation on the variable and the parameters in that operation.

[0044] The bytecode acquisition unit 213 acquires a bytecode to be referenced in order to decide whether or not to perform a preventative evaluation at the current location. The bytecode acquisition unit 213 outputs the acquired bytecode to the bytecode inspection unit 214.

[0045] The bytecode inspection unit 214 refers to the bytecode and decides whether or not to evaluate the variable appearing at the current position as the variable to be manipulated. In particular, the bytecode inspection unit 214 decides whether or not to perform a preventative evaluation of the variable appearing at the current position. The bytecode inspection unit 214 may also decide to evaluate the variable indicated in an instruction to be evaluated, such as a print statement, if it determines that such an instruction is at the current position. The bytecode inspection unit 214 outputs information to the evaluation unit 215 indicating whether or not evaluation of the variable is necessary.

[0046] The evaluation unit 215 evaluates a variable if the bytecode inspection unit 214 decides to evaluate that variable. Specifically, the evaluation unit 215 calculates the variable value by executing the intermediate representation output from the intermediate representation generation unit 212. If a variable is evaluated, the evaluation unit 215 outputs the evaluated variable value to the variable operation termination unit 216. On the other hand, if a variable is not evaluated, the evaluation unit 215 outputs the intermediate representation output from the intermediate representation generation unit 212 to the variable operation termination unit 216.

[0047] The variable operation termination unit 216 wraps the variable value (the specific processing result data obtained by evaluating the intermediate expression) or intermediate expression output from the evaluation unit 215 into the format of a source program variable and returns it to the source program.

[0048] (Example 1) The bytecode inspection unit 214 may decide to perform a preventative evaluation of all variables manipulated within the try block, and all variables manipulated before the exception handling block (before the try block).

[0049] Figure 5 shows a third example of a source program that includes exception handling. In the example in Figure 5, "df1", "df2", and "df3" all represent variable names. "df1 = …………" indicates that a value is assigned to the variable df1. "df2 = …………" indicates that a value is assigned to the variable df2. "df3 = …………" indicates that a value is assigned to the variable df3.

[0050] The assignment statement "df1 = …………" is an example of an operation on the variable df1. Executing the assignment statement "df1 = …………" is an example of evaluating the variable df1. The assignment statement "df2 = …………" is an example of an operation on the variable df2. Executing the assignment statement "df2 = …………" is an example of evaluating the variable df2. The assignment statement "df3 = …………" is an example of an operation on the variable df3. Executing the assignment statement "df3 = …………" is an example of evaluating the variable df3.

[0051] Furthermore, part B31 of the source program in Figure 5 corresponds to an example of an exception handling block. Part B31 includes parts B32 and B33. Part B32 is the try block in the exception handling block of part B31. Section B33 is the except block in the exception handling block of section B31. Section B33 shows the actions that should be taken when an exception is detected in section B32.

[0052] Furthermore, position P31 indicates the location of the assignment statement "df1 = …………". Position P32 indicates the location of the assignment statement "df2 = …………". Position P33 indicates the location of the assignment statement "df3 = …………". In the first example, the bytecode inspection unit 214 determines that all variables manipulated within the exception handling block should be evaluated in order to prevent overlooking any errors.

[0053] In the example in Figure 5, when the current position is position P31, the bytecode inspection unit 214 decides to evaluate the variable df1. At position P31, the evaluation of the variable df1 is performed by executing the assignment statement "df1 = …………". Furthermore, when the current position is position P32, the bytecode inspection unit 214 decides to evaluate the variable df2. At position P32, the evaluation of the variable df2 is performed by executing the assignment statement "df2 = …………". Furthermore, when the current position is position P33, the bytecode inspection unit 214 decides to evaluate the variable df3. At position P33, the evaluation of the variable df3 is performed by executing the assignment statement "df3 = …………". The evaluation unit 215 can prevent oversights by evaluating the variables that the byte code inspection unit 214 has decided to evaluate.

[0054] Figure 6 shows a fourth example of a source program that includes exception handling. In the example in Figure 6, "df4", "df5", and "df6" all represent variable names. "df4 = …………" indicates that a value is assigned to the variable df4. "df5 = …………" indicates that a value is assigned to the variable df5. "df6 = …………" indicates that a value is assigned to the variable df6.

[0055] The assignment statement "df4 = …………" is an example of an operation on the variable df4. Executing the assignment statement "df4 = …………" is an example of evaluating the variable df4. The assignment statement "df5 = …………" is an example of an operation on the variable df5. Executing the assignment statement "df5 = …………" is an example of evaluating the variable df5. The assignment statement "df6 = …………" is an example of an operation on the variable df6. Executing the assignment statement "df6 = …………" is an example of evaluating the variable df6.

[0056] Furthermore, part B41 of the source program in Figure 6 is an example of an exception handling block. The exception handling block in part B41 includes a try block and an except block. Furthermore, position P41 indicates the location of the assignment statement "df4 = …………". Position P42 indicates the location of the assignment statement "df5 = …………". Position P43 indicates the location of the assignment statement "df6 = …………". In the first example, the bytecode inspection unit 214 determines that all variables manipulated before the exception handling block (on the opposite side of the program execution direction) should be evaluated in order to prevent false positives.

[0057] In the example in Figure 6, when the current position is position P41, the bytecode inspection unit 214 decides to evaluate the variable df4. At position P41, the evaluation of the variable df4 is performed by executing the assignment statement "df4 = …………". Furthermore, when the current position is position P42, the bytecode inspection unit 214 decides to evaluate the variable df5. At position P42, the evaluation of the variable df5 is performed by executing the assignment statement "df5 = …………". Furthermore, when the current position is position P43, the bytecode inspection unit 214 decides to evaluate the variable df6. At position P43, the evaluation of the variable df6 is performed by executing the assignment statement "df6 = …………". The evaluation unit 215 can prevent false positives by evaluating the variables that the byte code inspection unit 214 has decided to evaluate.

[0058] Figure 7 shows a first example of the configuration of the bytecode inspection unit 214. In the configuration of Figure 7, the bytecode inspection unit 214a comprises an exception handling block search unit 214a-1 and a preventive evaluation necessity determination unit 214a-2. Byte code inspection unit 214a is an example of byte code inspection unit 214.

[0059] The exception handling block search unit 214a-1 searches for an exception handling block by referring to the byte code converted from the source program. If an exception handling block is found, the exception handling block search unit 214a-1 detects the positional relationship between the exception handling block and the current position.

[0060] The preventative evaluation necessity determination unit 214a-2 determines, based on the search results from the exception handling block search unit 214a-1, whether the condition is met that the entire exception handling block, or a part of the exception detection target portion (try block) within the exception handling block, is located further in the direction of program execution than the current position. Having a part of the exception detection target portion located further in the direction of program execution than the current position means that the current position is located within a try block.

[0061] If the unit determines that such conditions are met, the preventative evaluation necessity determination unit 214a-2 decides to perform an evaluation on the variables that appear at the current position as variables to be manipulated. If multiple variables appear at the current position as variables to be manipulated, the preventative evaluation necessity determination unit 214a-2 decides to perform an evaluation on all variables that appear at the current position as variables to be manipulated.

[0062] The process performed by the bytecode inspection unit 214a is an example of a process that detects the variable to be evaluated at the current position from the current position if it determines that the entire exception handling block is located further in the direction of program execution than the current position, or that the current position is inside a try block.

[0063] Furthermore, the processing performed by the bytecode inspection unit 214a can be described as preventing missed detections or false positives by evaluating all variables being manipulated at the current position when it determines that there is a possibility of a missed detection or false positive. This can be seen as a naive method for preventing missed detections or false positives.

[0064] (Second example) To prevent overlooking errors in the first example above, the bytecode inspection unit 214 may exclude variables that have the opportunity to be evaluated later than the current position (towards the direction of program execution) and before the end of the try block from being evaluated at the current position. Furthermore, in order to prevent false positives in the first example described above, the bytecode inspection unit 214 may exclude from evaluation at the current position variables that have the opportunity to be evaluated later than the current position (towards the direction of program execution) and before the beginning of the exception handling block (on the opposite side of the direction of program execution).

[0065] Figure 8 shows a fifth example of a source program that includes exception handling. Figure 8 also shows an example of a scenario in which a preventative evaluation is performed to prevent false positives. In the example in Figure 8, "df1", "df2", "df3", "df4", and "df5" all represent variable names. "df1 = …………" indicates that a value is assigned to the variable df1. "df2 = df1.…………" indicates that the value calculated by referencing variable df1 is assigned to variable df2. "df3 = df2.…………" indicates that the value calculated by referencing variable df2 is assigned to variable df3. "df4 = …………" indicates that a value is assigned to variable df4. "df5 = df4.…………" indicates that the value calculated by referencing variable df4 is assigned to variable df5.

[0066] The assignment statement "df1 = …………" is an example of an operation on the variable df1. Executing the assignment statement "df1 = …………" is an example of evaluating the variable df1. The assignment statement "df2 = df1.…………" is an example of an operation on the variable df2. Executing the assignment statement "df2 = df1.…………" is an example of evaluating the variable df2. Furthermore, obtaining the value of the variable df1 when executing the assignment statement "df2 = df1.…………" is an example of evaluating the variable df1. The assignment statement "df3 = df2.…………" is an example of an operation on the variable df3. Executing the assignment statement "df3 = df2.…………" is an example of evaluating the variable df3. Furthermore, obtaining the value of the variable df2 when executing the assignment statement "df3 = df2.…………" is an example of evaluating the variable df2.

[0067] The assignment statement "df4 = …………" is an example of an operation on the variable df4. Executing the assignment statement "df4 = …………" is an example of evaluating the variable df4. The assignment statement "df5 = df4.…………" is an example of an operation on the variable df5. Executing the assignment statement "df5 = df4.…………" is an example of evaluating the variable df5. Furthermore, obtaining the value of the variable df4 when executing the assignment statement "df5 = df4.…………" is an example of evaluating the variable df4.

[0068] Furthermore, part B51 of the source program in Figure 8 is an example of an exception handling block. The exception handling block in part B51 includes a try block and an except block. Furthermore, position P51 indicates the position of the assignment statement "df1 = …………". Position P52 indicates the position of the assignment statement "df2 = df1.…………". Position P53 indicates the position of the assignment statement "df3 = df2.…………". Position P54 indicates the position of the assignment statement "df4 = …………". Position P55 indicates the position of the assignment statement "df5 = df4.…………".

[0069] In the example in Figure 8, the value of variable df3 requires the value of variable df2, and the value of variable df2 requires the value of variable df1. Furthermore, the value of variable df5 requires the value of variable df4. The bytecode inspection unit 214 analyzes the dependencies (referencing relationships) of such variable values ​​in the range after the current position and before the exception handling block (part B51 in the example in Figure 8). Then, if a variable appearing at the current position as a variable to be manipulated has an opportunity to be evaluated in the range after the current position and before the exception handling block, the bytecode inspection unit 214 decides to exclude that variable from evaluation at the current position. In other words, it excludes that variable from evaluation at the current position. Information that represents the dependencies between variable values ​​using a column of variable names is also called a variable manipulation column. In the example in Figure 8, the dependencies between variable values ​​can be represented by two variable manipulation columns: df1-df2-df3 and d4-df5.

[0070] In the example shown in Figure 8, at position P51, the byte code inspection unit 214 determines that variable df1 is not to be evaluated at the current position. Also, at position P52, the byte code inspection unit 214 determines that variables df2 and df1 are not to be evaluated at the current position. On the other hand, in the range after position P53 and before section B51, there is no opportunity to evaluate the variable df3. Therefore, at position P53, the byte code inspection unit 214 decides to evaluate the variable df3. In accordance with this decision, the evaluation unit 215 evaluates variable df3 at position P53. At position P53, the evaluation unit 215 evaluates variable df2 in order to evaluate variable df3, and evaluates variable df1 in order to evaluate variable df2. This prevents false detections for variables df1, df2, and df3.

[0071] For example, when the second example is implemented in combination with the first example (i.e., when the second example is implemented in relation to the first example), deciding to exclude variables that have the opportunity to be evaluated in a range after the current position but before the exception handling block from evaluation at the current position can be understood as detecting a variable as a variable to be evaluated at the current position if it is determined that the entire exception handling block is located further along the program execution direction from the current position, and that the variable appearing at the current position as an manipulated variable does not appear further along the program execution direction from the current position beyond the start of the exception handling block.

[0072] To prevent overlooking an issue, the bytecode inspection unit 214 analyzes the dependencies between variable values ​​in the range from the current position to the end of the try block. If a variable appearing at the current position as a variable to be manipulated has an opportunity to be evaluated later in the range from the current position to the end of the try block, the bytecode inspection unit 214 decides to exclude that variable from evaluation at the current position.

[0073] For example, when the second example is implemented in combination with the first example, deciding to exclude a variable from evaluation at the current position that has the opportunity to be evaluated later than the current position and within the scope of the try block can be understood as detecting a variable to be evaluated when the current position is located within a try block and it is determined that the variable appearing at the current position as a variable being manipulated will not appear again further in the direction of program execution from the current position until the end of the exception detection target section. This allows the information processing device 100 to prevent overlooking information.

[0074] Figure 9 shows a second example of the configuration of the bytecode inspection unit 214. In the configuration of Figure 9, the bytecode inspection unit 214b comprises an exception handling block search unit 214a-1, a variable operation sequence tracking unit 214b-1, and a preventive evaluation necessity determination unit 214b-2. Byte code inspection unit 214b corresponds to an example of byte code inspection unit 214. Furthermore, among the parts in Figure 9, those that have the same function as the parts in Figure 7 are denoted by the same reference numeral (214a-1), and detailed explanations are omitted here.

[0075] The variable manipulation sequence tracking unit 214b-1 analyzes the dependency relationships between variable values ​​when the exception handling block search unit 214a-1 detects an exception handling block. If the current position is determined to be before the exception handling block (i.e., if it is determined that there is a possibility of a false positive), the variable operation sequence tracking unit 214b-1 determines whether the variable appearing at the current position as the variable to be operated on has an opportunity to be evaluated after the current position but before the start position of the exception handling block. Furthermore, if the current position is determined to be within a try block (i.e., if there is a possibility of oversight), the variable manipulation sequence tracking unit 214b-1 determines whether the variable appearing at the current position as a variable to be manipulated will have an opportunity to be evaluated later than the current position and before the end of the try block.

[0076] The preventative evaluation necessity determination unit 214b-2 determines whether or not to perform a preventative evaluation at the current position for the variable appearing at the current position, based on the search results from the exception handling block search unit 214a-1 and the analysis results from the variable operation sequence tracking unit 214b-1. For example, when the second example is implemented in combination with the first example, the preventive evaluation necessity determination unit 214b-2 determines whether or not to perform a preventive evaluation at the current location as follows.

[0077] If an exception handling block is detected after the current position, and it is determined that the variable appearing at the current position as the variable to be manipulated will not have the opportunity to be evaluated after the current position but before the start of the exception handling block, the preventive evaluation necessity determination unit 214b-2 decides to perform a preventive evaluation on that variable at the current position. Furthermore, if it is determined that the current position is within a try block, and that the variable appearing at the current position as the variable to be manipulated will not have the opportunity to be evaluated after the current position and before the end of the try block, the preventive evaluation necessity determination unit 214b-2 decides to perform a preventive evaluation on that variable at the current position.

[0078] On the other hand, if no exception handling block is detected after the current position, and it is determined that the current position is not located within a try block, the preventative evaluation necessity determination unit 214b-2 decides not to perform a preventative evaluation at the current position for the variables that appear at the current position as variables to be manipulated. If the current position is determined to be before the exception handling block, and if it is determined that the variable appearing at the current position as the variable to be manipulated will have an opportunity to be evaluated later than the current position but before the start of the exception handling block, the preventive evaluation necessity determination unit 214b-2 will decide not to perform a preventive evaluation on that variable at the current position. Furthermore, if the current position is determined to be within a try block, and it is determined that a variable appearing at the current position as a variable to be manipulated will have an opportunity to be evaluated later than the current position and before the end of the try block, the preventive evaluation necessity determination unit 214b-2 also decides not to perform a preventive evaluation on that variable at the current position.

[0079] The process performed by the bytecode inspection unit 214b is an example of a process that detects the variable to be evaluated at the current position from the current position if it determines that the entire exception handling block is located in the direction of program execution progress, or that the current position is located within a try block.

[0080] Furthermore, the processing performed by the bytecode inspection unit 214b can be understood as excluding the variable from evaluation at the current position if it determines that a variable currently appearing as an manipulated variable appears later than the current position but before the end of the try block, and if it determines that a variable currently appearing as an manipulated variable appears later than the current position but before the start of the exception handling block, in situations where a false positive may occur. The situation in which a false positive may occur is when the current position is located within a try block. The situation in which a false positive may occur is when the entire exception handling block is located after the current position. By delaying the evaluation of variables that appear at the current position, their evaluation can be delayed. Delaying the evaluation of variables increases the likelihood of optimizing the intermediate representation.

[0081] Furthermore, in situations where an oversight may occur, if there is a conditional statement or loop after the current position and within a try block, and in situations where a false positive may occur, if there is a conditional statement or loop after the current position and before the start of the meeting processing block, it is expected that the necessity of preventive evaluation can be determined with higher accuracy by performing the processing as in the fourth example described later. The accuracy of determining the necessity of preventive evaluation here can be evaluated by the degree to which exception handling is performed (how similarly exception handling is performed) when the program is executed with lazy evaluation and when it is executed sequentially.

[0082] (Third example) To prevent false positives in the first example above, or in the second example above, the bytecode inspection unit 214 may exclude variables not used within the exception handling block from evaluation at the current position.

[0083] Figure 10 shows a sixth example of a source program that includes exception handling. Figure 10 also shows an example of a scenario in which a preventative evaluation is performed to prevent false positives. In the example in Figure 10, "df6" represents the variable name. "df6 = …………" indicates that a value is assigned to the variable df6. Executing the assignment statement "df6 = …………" is an example of evaluating the variable df6.

[0084] Furthermore, part B61 of the source program in Figure 10 corresponds to an example of an exception handling block. The exception handling block in part B61 includes a try block and an except block. In the example in Figure 10, the variable df6 does not appear within the exception handling block of part B61.

[0085] Furthermore, position P61 indicates the location of the assignment statement "df6 = …………". Position P62 indicates the location of the return statement "return df6". The return statement "return df6" indicates that the function containing the part of the program shown in Figure 10 is terminated and the value of the variable df6 is returned as the return value. In the return statement "return df6", the variable df6 is evaluated.

[0086] In the example in Figure 10, the variable df6 does not appear within the exception handling block, so even if the variable df6 is not evaluated at position P61, no false positive will occur. Furthermore, even if the variable df6 is not located within the exception handling block, it may be used in the calculation of the value of another variable, such as in the assignment statement "df7 = df6. ……………", and the other variable (for example, variable df7) may appear within the exception handling block. In this case, since variable df6 will be evaluated when the other variable is evaluated, even if variable df6 is not evaluated at position P61, no false positive will occur.

[0087] Thus, if a variable that appears at the current position as a variable to be manipulated does not appear in any exception handling block after the current position, the bytecode inspection unit 214 excludes that variable from the preventative evaluation at the current position. By delaying the evaluation of variables that appear at the current position, their evaluation can be delayed. Delaying the evaluation of variables increases the likelihood of optimizing the intermediate representation.

[0088] Figure 11 shows a third example of the configuration of the bytecode inspection unit 214. In the configuration of Figure 11, the bytecode inspection unit 214c comprises an exception handling block search unit 214a-1, an exception handling block variable tracking unit 214c-1, and a preventive evaluation necessity determination unit 214c-2. Byte code inspection unit 214c corresponds to an example of byte code inspection unit 214. Furthermore, among the parts in Figure 11, those that have the same function as the parts in Figure 7 are denoted by the same reference numeral (214a-1), and detailed explanations are omitted here.

[0089] The variable tracking unit 214c-1 within the exception handling block determines whether a variable appearing at the current position as a variable to be manipulated appears within the exception handling block if the exception handling block search unit 214a-1 detects the entire exception handling block after the current position. The preventive evaluation necessity determination unit 214c-2 determines whether or not to perform a preventive evaluation at the current position for the variable appearing at the current position, based on the search results from the exception handling block search unit 214a-1 and the determination result from the variable tracking unit within the exception handling block 214c-1.

[0090] For example, when the third example is implemented in combination with the first example, the preventive evaluation necessity determination unit 214c-2 determines whether or not to perform a preventive evaluation at the current location as follows. If the entire exception handling block is detected after the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated also appears within the exception handling block, the preventative evaluation necessity determination unit 214c-2 decides to perform a preventative evaluation on that variable at the current position. Furthermore, if it is determined that the current position is within a try block, the preventive evaluation necessity determination unit 214c-2 decides to perform a preventive evaluation at the current position for the variables that appear at the current position as variables to be manipulated.

[0091] On the other hand, if no exception handling block is detected after the current position, and it is determined that the current position is not located within a try block, the preventative evaluation necessity determination unit 214c-2 decides not to perform a preventative evaluation at the current position for the variables that appear at the current position as variables to be manipulated. If an exception handling block is detected after the current position, and it is determined that the variable appearing at the current position as a variable to be manipulated does not appear within the exception handling block, the preventative evaluation necessity determination unit 214c-2 also decides not to perform a preventative evaluation on that variable at the current position.

[0092] The process performed by the bytecode inspection unit 214c is an example of a process that detects the variable to be evaluated at the current position from the current position when it determines that the entire exception handling block, or a part of the exception handling block that is subject to exception detection, is located further in the direction of program execution than the current position.

[0093] Thus, if the bytecode inspection unit 214c determines that the entire exception handling block is located in the direction of program execution progress beyond the current position, and that a variable appearing at the current position as a variable to be manipulated does not appear within the exception handling block, it excludes that variable from the preventative evaluation at the current position. By delaying the evaluation of variables that appear at the current position, their evaluation can be delayed. Delaying the evaluation of variables increases the likelihood of optimizing the intermediate representation.

[0094] (Fourth example) If a variable appearing at the current position as a variable to be manipulated also appears within a conditional statement or a loop, the bytecode inspection unit 214 may, when deciding whether or not to perform a preventative evaluation at the current position, exclude the conditional statement or loop from consideration to ensure a safe decision that avoids oversights or false positives.

[0095] Figure 12 shows a seventh example of a source program that includes exception handling. Figure 12 also shows an example of a scenario in which a preventative evaluation is performed to prevent false positives. In the example in Figure 12, "df1" represents the variable name. "df1 = …………" indicates that a value is assigned to the variable df1. Also, "print(df1)" indicates that the value of the variable df1 is output, such as by displaying the value of the variable df1. The assignment statement "df1 = …………" is an example of an operation on the variable df1. Executing the assignment statement "df1 = …………" and executing the print command "print(df1)" are both examples of evaluating the variable df1.

[0096] Furthermore, part B71 of the source program in Figure 12 corresponds to an example of a conditional statement. Section B72 is an example of an exception handling block. The exception handling block in section B72 includes a try block and an except block. Furthermore, position P71 indicates the location of the assignment statement "df1 = …………". Also, the print command "print(df1)" is located within the conditional statement in section B71. Part B71 is located after position P71, and part B72 is located after part B71.

[0097] Now, let's consider the case where the current position is position P71, and the bytecode inspection unit 214 determines whether or not to perform a preventative evaluation of the variable df1 that appears at position P71. In this case, if the print command "print(df1)" within the conditional statement of section B71 is executed, then, according to the second example, the bytecode inspection unit 214 may decide not to perform a preventative evaluation of the variable df1 at position P71.

[0098] However, at the current position P71, it is unclear whether the print command "print(df1)" within the conditional statement of section B71 is executed. Furthermore, the variable df2 does not appear outside the conditional statement of section B71 within the range after position P71 and before the exception handling block of section B72.

[0099] Therefore, the bytecode inspection unit 214 decides to perform a preventative evaluation of the variable df1 at position P71. Specifically, the bytecode inspection unit 214 decides to execute the assignment statement "df1 = …………" at position P71. This prevents false detections caused by delayed evaluation of the variable df1 appearing in section B71, even when the print command "print(df1)" within the conditional statement of section B71 is not executed.

[0100] Figure 13 shows an example of a source program with exception handling. Figure 13 also shows an example of a scenario in which a preventative evaluation is performed to prevent false positives. In the example in Figure 13, "df2" represents the variable name. "df2 = …………" indicates that a value is assigned to the variable df2. Also, "print(df2)" indicates that the value of the variable df2 is output, such as by displaying the value of the variable df2. The assignment statement "df2 = …………" is an example of an operation on the variable df2. Executing the assignment statement "df2 = …………" and executing the print command "print(df2)" are both examples of evaluating the variable df2.

[0101] Furthermore, part B81 of the source program in Figure 13 corresponds to an example of a loop. Section B82 is an example of an exception handling block. The exception handling block in section B82 includes a try block and an except block. Furthermore, position P81 indicates the location of the assignment statement "df2 = …………". Also, the print command "print(df1)" is located within the conditional statement in section B71. Part B81 is located after position P81, and part B82 is located after part B81.

[0102] Now, let's consider the case where the current position is position P81, and the bytecode inspection unit 214 determines whether or not to perform a preventative evaluation of the variable df2 that appears at position P81. In this case, if the print command "print(df2)" within the conditional statement of section B81 is executed, then, according to the second example, the bytecode inspection unit 214 may decide not to perform a preventative evaluation of the variable df2 at position P81.

[0103] However, at the current position P81, it is unclear whether the print command "print(df2)" within the loop in section B81 will be executed. In particular, the loop may be executed 0 times. Also, the variable df2 does not appear outside the loop in section B81, within the range after position P81 and before the exception handling block in section B82.

[0104] Therefore, the bytecode inspection unit 214 decides to perform a preventative evaluation of the variable df2 at position P81. Specifically, the bytecode inspection unit 214 decides to execute the assignment statement "df1 = …………" at position P81. This prevents false detections caused by delayed evaluation of the variable df2 appearing in section B81, even when the print command "print(df2)" within the loop in section B81 is not executed.

[0105] Thus, if there is a conditional statement or loop after the current position, an exception handling block after the conditional statement or loop, and the variable appearing at the current position as the variable being manipulated does not appear outside the conditional statement or loop within the range after the current position and before the exception handling block, then deciding to perform a preventative evaluation of the variable appearing at the current position as the variable being manipulated can be seen as detecting that variable as the variable to be evaluated at the current position.

[0106] Figure 14 shows a ninth example of a source program that includes exception handling. Figure 14 also shows an example of a scenario in which a preventative evaluation is performed to prevent oversights. In the example in Figure 14, "df3" represents the variable name. "df3 = …………" indicates that a value is assigned to the variable df3. Also, "print(df3)" indicates that the value of the variable df3 is output, such as by displaying the value of the variable df3. The assignment statement "df3 = …………" is an example of an operation on the variable df3. Executing the assignment statement "df3 = …………" and executing the print command "print(df3)" are both examples of evaluating the variable df3.

[0107] Furthermore, part B91 of the source program in Figure 14 corresponds to an example of an exception handling block. Part B91 includes parts B92 and B94. Part B92 is the try block in the exception handling block of part B91. Section B94 is the except block in the exception handling block of section B91. Section B94 shows the actions that should be taken when an exception is detected in section B92.

[0108] Furthermore, section B92 includes positions P91 and B93. Position P91 indicates the location of the assignment statement "df3 = …………". Section B93 corresponds to an example of a conditional statement. Also, section B93 includes the print command "print(df3)". Within section B92, section B93 is located after position P91.

[0109] Now, let's consider the case where the current position is position P91, and the bytecode inspection unit 214 determines whether or not to perform a preventative evaluation of the variable df3 that appears at position P91. In this case, if the print command "print(df3)" within the conditional statement of section B93 is executed, then, according to the second example, the bytecode inspection unit 214 may decide not to perform a preventative evaluation of the variable df3 at position P91.

[0110] However, at the current position P91, it is unclear whether the print command "print(df3)" within the conditional statement in section B93 is executed. Furthermore, after position P91, and within the try block of section B92, the variable df3 does not appear outside the conditional statement in section B93.

[0111] Therefore, the bytecode inspection unit 214 decides to perform a preventative evaluation of the variable df3 at position P91. Specifically, the bytecode inspection unit 214 decides to execute the assignment statement "df3 = …………" at position P91. This prevents the variable df3 appearing in section B91 from being overlooked due to delayed evaluation, even when the print command "print(df3)" within the conditional statement in section B93 is not executed.

[0112] Figure 15 shows a tenth example of a source program that includes exception handling. Figure 15 also shows an example of a scenario in which a preventative evaluation is performed to prevent oversights. In the example in Figure 15, "df4" represents the variable name. "df4 = …………" indicates that a value is assigned to the variable df4. Also, "print(df4)" indicates that the value of the variable df4 is output, such as by displaying the value of the variable df4. The assignment statement "df4 = …………" is an example of an operation on the variable df4. Executing the assignment statement "df4 = …………" and executing the print command "print(df4)" are both examples of evaluating the variable df4.

[0113] Furthermore, part B101 of the source program in Figure 15 corresponds to an example of an exception handling block. Part B101 includes parts B102 and B104. Part B102 is the try block in the exception handling block of part B101. Section B104 is the except block in the exception handling block of section B101. Section B104 shows the actions that should be taken when an exception is detected in section B102.

[0114] Furthermore, section B102 includes positions P101 and B103. Position P101 indicates the location of the assignment statement "df4 = …………". Section B103 corresponds to an example of a loop. Also, section B103 includes the print command "print(df4)". Within section B102, section B103 is located after position P101.

[0115] Now, let's consider the case where the current position is position P101, and the bytecode inspection unit 214 determines whether or not to perform a preventative evaluation of the variable df4 that appears at position P101. In this case, if the print command "print(df4)" within the conditional statement of section B103 is executed, then, according to the second example, the bytecode inspection unit 214 may decide not to perform a preventative evaluation of the variable df4 at position P101.

[0116] However, at the current position P101, it is unclear whether the print command "print(df4)" within the loop in section B103 is executed. Also, after position P101, and within the try block of section B102, the variable df4 does not appear outside the loop in section B103.

[0117] Therefore, the bytecode inspection unit 214 decides to perform a preventative evaluation of the variable df4 at position P101. Specifically, the bytecode inspection unit 214 decides to execute the assignment statement "df4 = …………" at position P101. This prevents the variable df4 appearing in section B101 from being overlooked due to delayed evaluation, even when the print command "print(df4)" within the loop in section B103 is not executed.

[0118] Thus, if the current position is within a try block, and there is a conditional statement or loop after the current position within the try block, and a variable appearing at the current position does not appear after the current position outside of the conditional statement or loop within the try block, then deciding to perform a preventative evaluation of that variable at the current position can be seen as detecting that variable as a variable to be evaluated at the current position.

[0119] Figure 16 shows a fourth example of the configuration of the bytecode inspection unit 214. In the configuration of Figure 16, the bytecode inspection unit 214d comprises an exception handling block search unit 214a-1, a branch search unit 214d-1, and a preventive evaluation necessity determination unit 214d-2. The byte code inspection unit 214d is an example of the byte code inspection unit 214. Furthermore, among the parts in Figure 16, those that have the same function as the parts in Figure 7 are denoted by the same reference numeral (214a-1), and detailed explanations are omitted here.

[0120] If the branch search unit 214d-1 detects an exception handling block after the current position, it determines whether there is a conditional statement or loop after the current position and before the exception handling block. Furthermore, if the exception handling block search unit 214a-1 determines that the current position is within a try block, the branch search unit 214d-1 determines whether there is a conditional statement or loop after the current position and within a try block.

[0121] The preventive evaluation necessity determination unit 214d-2 determines whether or not to perform a preventive evaluation at the current position for the variable appearing at the current position, based on the search results from the exception handling block search unit 214a-1 and the search results from the branch search unit 214d-1. For example, when the fourth example is implemented in combination with the first and second examples, the preventive evaluation necessity determination unit 214d-2 determines whether or not to perform a preventive evaluation at the current location as follows.

[0122] If an exception handling block is detected after the current position, and a conditional statement or loop is detected after the current position but before the exception handling block, and it is determined that the variable appearing at the current position as an manipulated variable does not appear outside the conditional statement or loop after the current position but before the exception handling block, the preventive evaluation necessity determination unit 214d-2 decides to perform a preventive evaluation on the variable appearing at the current position.

[0123] If an exception handling block is detected after the current position, and a conditional statement or loop is detected after the current position but before the exception handling block, and the variable appearing at the current position as the variable being manipulated is determined to have appeared outside the conditional statement or loop after the current position but before the exception handling block, the preventive evaluation necessity determination unit 214d-2 decides not to perform a preventive evaluation on the variable appearing at the current position.

[0124] If an exception handling block is detected after the current position, and no conditional statement or loop is detected after the current position but before the exception handling block, the preventative evaluation necessity determination unit 214d-2, similar to the preventative evaluation necessity determination unit 214b-2 in the second example, decides whether or not to perform a preventative evaluation at the current position for the variables appearing at the current position.

[0125] If the current position is determined to be within a try block, and a conditional statement or loop is detected after the current position and within a try block, and the variable appearing at the current position as an manipulated variable does not appear after the current position and within a try block outside of the conditional statement or loop, the preventive evaluation necessity determination unit 214d-2 decides to perform a preventive evaluation at the current position.

[0126] If an exception handling block is detected after the current position, and a conditional statement or loop is detected after the current position and within a try block, and the variable that appears at the current position as the variable being manipulated also appears after the current position and within a try block but outside the conditional statement or loop, the preventive evaluation necessity determination unit 214d-2 decides not to perform a preventive evaluation at the current position.

[0127] If it is determined that the current position is within a try block, and no conditional statements or loops are detected after the current position and within the try block, the preventative evaluation necessity determination unit 214d-2, similar to the preventative evaluation necessity determination unit 214b-2 in the second example, decides whether or not to perform a preventative evaluation at the current position for the variables appearing at the current position.

[0128] The process performed by the bytecode inspection unit 214d is an example of a process that detects the variable to be evaluated at the current position from the current position when it determines that the entire exception handling block, or a part of the exception handling block that is subject to exception detection, is located further in the direction of program execution than the current position.

[0129] Thus, if the bytecode inspection unit 214d determines that the entire exception handling block is located further in the direction of program execution than the current position, that there is a conditional statement or loop further in the direction of program execution than the current position and that is

[0130] Furthermore, if the bytecode inspection unit 214d determines that the current position is within the exception detection target portion of the exception handling block, that there is a conditional statement or loop between the current position and the exception detection target portion in the direction of program execution, and that a variable appearing at the current position as an manipulated variable appears outside the conditional statement or loop, up to the end position of the exception detection target portion in the direction of program execution, further than the current position, then the bytecode inspection unit 214d decides to exclude that variable from evaluation at the current position.

[0131] By delaying the evaluation of variables that appear at the current position, their evaluation can be delayed. Delaying the evaluation of variables increases the likelihood of optimizing the intermediate representation.

[0132] (Example 5) If the current position is within a function, the bytecode check unit 214 may also check for the presence of an exception handling block or a part of a try block after the function caller. The presence of a part of a try block after the function caller can be interpreted as the function caller being located within a try block.

[0133] Figure 17 shows an eleventh example of a source program that includes exception handling. Figure 17 also shows an example of a scenario in which a preventative evaluation is performed to prevent false positives. In the example in Figure 17, "df0" represents the variable name. "df0 = …………" indicates that a value is assigned to the variable df0. Position P112 indicates the location of the assignment statement "df0 = …………".

[0134] Furthermore, position P112 is located inside the function "myfunc". The function "myfunc" is called by "df1 = myfunc" at position P111. "return df0" inside the function "myfunc" is a return statement indicating that the function "myfunc" returns the value of the variable df0 as its return value. Furthermore, section B111 is an example of an exception handling block. Section B111 is located after position P111.

[0135] Now, let's consider the case where the current position is position P112, and the bytecode inspection unit 214 determines whether or not to perform a preventative evaluation of the variable df0 that appears at position P112. In this case, the bytecode inspection unit 214 determines whether there is an exception handling block and whether there is a part of a try block after position P112 and within the function "myfunc". Furthermore, the bytecode inspection unit 214 determines whether there is an exception handling block and whether there is a part of a try block after position P111, which is the caller of the function "myfunc". At that time, the bytecode inspection unit 214 traces back through the stack frame to find the position of the caller of the function "myfunc".

[0136] For example, when the fifth example is implemented in combination with the first example, the bytecode inspection unit 214 decides whether or not to perform a preventative evaluation at the current location as follows: If the bytecode inspection unit 214 determines that the entire exception handling block is located after position P112 (current position) and within the function "myfunc", if it determines that position P112 is located within a try block, if it determines that the entire exception handling block is located after position P111 (function caller), or if it determines that position P111 is located within a try block, the bytecode inspection unit 214 decides to perform a preventative evaluation at the current position. In the example in Figure 17, there is an exception handling block (part B111) after position P111 (function caller), and the bytecode inspection unit 214 decides to perform a preventative evaluation at the current position (position P112).

[0137] On the other hand, if the bytecode inspection unit 214 determines that there is no entire exception handling block after the current position and within the function, the current position is not located within a try block, there is no entire exception handling block after the function caller, and the function caller is not located within a try block, the bytecode inspection unit 214 decides not to perform a preventative evaluation at the current position.

[0138] The bytecode inspection unit 214 may determine whether the value of the variable appearing at the current position as the variable being manipulated is referenced when calculating the return value, and only if it determines that it is referenced, it may also determine whether there is an exception handling block and whether there is part of a try block after the function caller.

[0139] In the example shown in Figure 17, the bytecode inspection unit 214 detects that the variable df0 appearing at the current position is the return value of the function "myfunc", and determines that the value of variable df0 appearing at the current position is referenced when determining the return value. The bytecode inspection unit 214 then determines whether there is an exception handling block and whether there is a part of a try block after position P111, which is the caller of the function "myfunc".

[0140] Alternatively, the bytecode inspection unit 214 may determine, in all cases where the current position is within a function, whether there is an exception handling block and whether there is a part of a try block after the function caller. In this case, the bytecode inspection unit 214 can be seen as making a safe decision on whether or not to perform a preventative evaluation at the current position to avoid oversights or false positives. If function calls are nested, the bytecode inspection unit 214 may repeatedly perform a process to detect the function caller and determine the presence or absence of an exception handling block and part of a try block after the function caller.

[0141] Figure 18 shows a fifth example of the configuration of the bytecode inspection unit 214. In the configuration of Figure 18, the bytecode inspection unit 214e comprises an exception handling block search unit 214e-1, a function return search unit 214e-2, a stack frame trace unit 214e-3, and a preventative evaluation necessity determination unit 214e-4.

[0142] The exception handling block search unit 214e-1 determines whether the entire exception handling block is located after the current position, and whether the current position is located within a try block. In particular, if the current position is located within a function, the exception handling block search unit 214e-1 also treats the function caller as part of the current position. Specifically, the exception handling block search unit 214e-1 determines whether the entire exception handling block is located after the function caller, and whether the function caller is located within a try block.

[0143] The function return search unit 214e-2 determines whether the current position is inside a function by checking whether there is a return statement after the current position. Furthermore, the function return search unit 214e-2 may also determine whether the value of a variable appearing at the current position as a variable being manipulated is referenced when calculating the return value. The stack frame tracer 214e-3 traces back through the stack frame to find the function caller.

[0144] The preventive evaluation necessity determination unit 214e-4 determines whether or not to perform a preventive evaluation at the current location based on the determination result of the exception handling block search unit 214e-1. For example, when the fifth example is implemented in combination with the first example, the preventive evaluation necessity determination unit 214e-4 determines whether or not to perform a preventive evaluation at the current location as follows.

[0145] If the preventative evaluation necessity determination unit 214e-4 determines that there is an exception handling block or part of a try block after the current position and within a function, or if it determines that there is an exception handling block or part of a try block after the function's caller, it decides to perform a preventative evaluation at the current position. On the other hand, if the preventative evaluation necessity determination unit 214e-4 determines that there are no exception handling blocks or parts of try blocks after the current position and within the function, and that there are no exception handling blocks or parts of try blocks after the function caller, it decides not to perform a preventative evaluation at the current position.

[0146] The process performed by the bytecode inspection unit 214e is an example of a process that detects the variable to be evaluated at the current position from the current position when it determines that the entire exception handling block, or a part of the exception handling block that is subject to exception detection, is located further in the direction of program execution than the current position.

[0147] Thus, if the current position is within a function, the bytecode inspection unit 214e determines whether to detect a variable appearing at the current position as a variable to be evaluated at the current position, based on the program's direction of progress relative to the current position within that function, as well as the program's direction of progress relative to the function's caller. In this respect, the bytecode inspection unit 214e can determine with high accuracy whether a preventative evaluation is necessary, even when the current position is within a function.

[0148] If function calls are nested, the bytecode inspection unit 214e may traverse the function callers from the current function to the top-level function and decide whether or not to perform a preventative evaluation at the current position. That is, the bytecode inspection unit 214e may traverse the function callers from the current function to the top-level function and decide whether or not to detect a variable appearing at the current position as a variable being manipulated, based on the program's progress direction relative to each caller, as a variable to be evaluated at the current position.

[0149] (Example 6) If a function is called after the current position, the bytecode inspection unit 214 may decide whether or not to perform a preventative evaluation at the current position, depending on the function being called. To this end, a whitelist of functions that do not require preventative evaluation may be prepared in advance.

[0150] Figure 19 shows the twelfth example of a source program that includes exception handling. Figure 19 shows an example of a scenario in which a preventative evaluation is performed to prevent false positives. In the example in Figure 19, "df1" represents the variable name. "df1 = …………" indicates that a value is assigned to the variable df0. Position P121 indicates the position of the assignment statement "df1 = …………".

[0151] Furthermore, "myfunc(df1)" indicates that the function "myfunc" is called, passing the variable df1 as an argument. Position P122 indicates the location of the function call "myfunc(df1)". Furthermore, section B121 is an example of an exception handling block. Section B121 is located within the function "myfunc".

[0152] Here, we consider the case where the current position is position P121, and the bytecode inspection unit 214 determines whether or not to perform a preventative evaluation of the variable df1 that appears at position P121. Furthermore, we assume that there are no exception handling blocks other than the function "myfunc" after the current position P121.

[0153] In this case, the bytecode inspection unit 214 determines whether the function "myfunc" is on the whitelist. The whitelist contains function names that do not contain exception handling blocks. If there are any functions that will be called after the current location but are not on the whitelist, the bytecode inspection unit 214 decides to perform a precautionary evaluation at the current location. In the example shown in Figure 19, the function "myfunc" contains an exception handling block and is not on the whitelist. Therefore, the bytecode inspection unit 214 decides to perform a preventative evaluation at its current location, P121.

[0154] On the other hand, if all functions called after the current position are on the whitelist, and there are no exception handling blocks other than functions after the current position, the bytecode inspection unit 214 decides not to perform a preventative evaluation at the current position. In this case, it can be said that it has been detected that there are no exception handling blocks after the current position.

[0155] Figure 20 shows a sixth example of the configuration of the bytecode inspection unit 214. In the configuration of Figure 20, the bytecode inspection unit 214f ​​comprises an exception handling block search unit 214a-1, a function search unit 214f-1, a whitelist storage unit 214f-2, and a preventative evaluation necessity determination unit 214f-3.

[0156] The byte code inspection unit 214f ​​corresponds to an example of the byte code inspection unit 214. Furthermore, in Figure 20, parts that have the same function as the parts in Figure 7 are denoted by the same reference numeral (214a-1). In the example in Figure 20, the exception handling block search unit 214a-1 determines whether the current position is within a try block, and whether there is an exception handling block after the current position, other than the function being called.

[0157] The function search unit 214f-1 searches for functions that will be called after the current position. If a function is found, the function search unit 214f-1 outputs the function name of the found function to the preventative evaluation necessity determination unit 214f-3. The whitelist storage unit 214f-2 stores in advance a whitelist that indicates functions that do not contain exception handling blocks. Here, "in advance" may mean before the information processing device 100 starts executing the source program. The memory unit 180 may also include a whitelist memory unit 214f-2.

[0158] The preventative evaluation necessity determination unit 214f-3 determines whether or not to perform a preventative evaluation at the current location based on the search results from the exception handling block search unit 214a-1 and the search results from the function search unit 214f-1. If the exception handling block search unit 214a-1 determines that the current position is within a try block, if the exception handling block search unit 214a-1 finds an exception handling block after the current position, or if the function search unit 214f-1 finds a function that is not registered in the whitelist, the preventive evaluation necessity determination unit 214f-3 decides to perform a preventive evaluation at the current position.

[0159] In the example shown in Figure 19, the function search unit 214f-1 detects the function "myfunc". The detected function "myfunc" is not included in the whitelist stored by the whitelist storage unit 214f-2. Therefore, the preventative evaluation necessity determination unit 214f-3 decides to perform a preventative evaluation at the current location.

[0160] On the other hand, if the exception handling block search unit 214a-1 determines that the current position is not within a try block, and that there are no exception handling blocks after the current position, and the function search unit 214f-1 does not detect any functions that are not registered in the whitelist, then the preventive evaluation necessity determination unit 214f-3 decides not to perform a preventive evaluation at the current position.

[0161] The process performed by the bytecode inspection unit 214f ​​is an example of a process that detects the variable to be evaluated at the current position from the current position if it determines that the entire exception handling block, or a part of the exception handling block that is subject to exception detection, is located further in the direction of program execution than the current position.

[0162] Furthermore, the processing performed by the bytecode inspection unit 214d involves determining the possibility of missed detections and false positives, and deciding whether or not to perform a preventative evaluation at the current location. For functions called after the current location, this process is carried out using a whitelist.

[0163] You may combine all or part of the above examples 1 through 6. Figure 21 shows a seventh example of the configuration of the bytecode inspection unit 214. In the configuration of Figure 21, the bytecode inspection unit 214g comprises an exception handling block search unit 214e-1, a variable operation sequence tracking unit 214b-1, an exception handling block variable tracking unit 214c-1, a branch search unit 214d-1, a function return search unit 214e-2, a stack frame trace unit 214e-3, a function search unit 214f-1, a whitelist storage unit 214f-2, and a preventative evaluation necessity determination unit 214g-1.

[0164] In Figure 21, parts that have the same function as those in Figures 7, 9, 11, 16, 18, or 20 are denoted by the same reference numerals (214b-1, 214c-1, 214d-1, 214e-1, 214e-2, 214e-3, 214f-1, 214f-2), and detailed explanations are omitted here.

[0165] In Figure 21, the exception handling block search unit 214e-1, similar to the exception handling block search unit 214a-1 described in Figure 20, determines whether the current position is within a try block and whether there is an exception handling block after the current position for functions other than the one being called. As explained with reference to Figure 18, the exception handling block search unit 214e-1 traces back to the function caller and determines whether the current position is within a try block and whether there is an exception handling block after the current position. That is, in Figure 21, the exception handling block search unit 214e-1 traces back to the function caller and determines whether the current position is within a try block and whether there is an exception handling block after the current position for functions other than the one being called.

[0166] The preventive evaluation necessity determination unit 214g-1 determines whether to perform a preventive evaluation at the current location based on the search results from the exception handling block search unit 214e-1, the search results from the variable operation sequence tracking unit 214b-1, the search results from the variable tracking unit within the exception handling block 214c-1, the search results from the branch search unit 214d-1, and the search results from the function search unit 214f-1. As shown in Figure 22, the preventive evaluation necessity determination unit 214g-1 performs a comprehensive processing of the processes performed by the preventive evaluation necessity determination units 214a-2, 214b-2, 214c-2, 214d-2, 214e-4, and 214f-3 to determine whether to perform a preventive evaluation at the current location.

[0167] Figure 22 shows an example of the procedure for determining whether or not to perform a preventative evaluation at the current location of the information processing device 100. In the following explanation, the process in Figure 22 will be described using the case where the byte code inspection unit 214 has the configuration of the byte code inspection unit 214g shown in Figure 21 as an example.

[0168] (Step S101) The bytecode acquisition unit 213 acquires the bytecode obtained from the converted source program. The information processing device 100 analyzes the source program by analyzing the bytecode. After step S101, the process proceeds to step S102.

[0169] (Step S102) The exception handling block search unit 214a-1 searches for exception handling blocks after the current position. If the current position is within a function, the exception handling block search unit 214a-1 treats the section after the function call as being after the current position and searches for the exception handling block. This corresponds to the processing in the fifth example described above. If the fifth example is not implemented, the exception handling block search unit 214a-1 may be configured to assume that an exception handling block has been detected when the current position is within a function. Alternatively, the section outside of a function may be excluded from the determination by the bytecode inspection unit 214g. After step S102, the process proceeds to step S103.

[0170] (Step S103) The function search unit 214f-1 searches for function calls after the current position. If the current position is within a function, the function search unit 214f-1 may treat the part after the function call as being after the current position when searching for a function call. This corresponds to the processing in the fifth example described above. If the fifth example is not implemented, when the current position is within a function, instead of the exception handling block search unit 214a-1 detecting an exception handling block, the function search unit 214f-1 may detect a function that is not on the whitelist. Alternatively, anything outside of a function may be excluded from the determination by the bytecode inspection unit 214g. After step S103, the process proceeds to step S104.

[0171] (Step S104) The preventative evaluation necessity determination unit 214g-1 determines whether or not the entire exception handling block is located after the current position. If the exception handling block search unit 214a-1 detects the entire exception handling block located after the current position in the process of step S102, the preventative evaluation necessity determination unit 214g-1 determines that the entire exception handling block is located after the current position.

[0172] In step S103, if the function search unit 214f-1 detects a call to a function not listed in the whitelist after the current position, the preventative evaluation necessity determination unit 214g-1 also determines that the entire exception handling block exists after the current position. This corresponds to the processing in the sixth case described above. If the information processing device 100 does not have a whitelist storage unit 214f-2, the preventative evaluation necessity determination unit 214g-1 may determine that the entire exception handling block exists after the current position when the function search unit 214f-1 detects a call to a function not listed in the whitelist after the current position. Alternatively, if the sixth example is not implemented, the functions called by the function call may be excluded from the determination by the bytecode inspection unit 214g.

[0173] If the preventative evaluation necessity determination unit 214g-1 determines that the entire exception handling block is located after the current position (step S104: YES), the process proceeds to step S111. On the other hand, if the preventative evaluation necessity determination unit 214g-1 determines that there is no entire exception handling block after the current position (step S104: NO), the process proceeds to step S121.

[0174] (Step S111) The bytecode inspection unit 214g decides whether or not to perform a preventative evaluation at the current location to prevent false detections. After step S111, the information processing device 100 terminates the process shown in Figure 22.

[0175] (Step S121) The preventative evaluation necessity determination unit 214g-1 determines whether the current position is within a try block. If the exception handling block search unit 214a-1 detects a part of a try block immediately after the current position in the processing of step S102, the preventative evaluation necessity determination unit 214g-1 determines that the current position is within a try block.

[0176] If the preventative evaluation necessity determination unit 214g-1 determines that the current position is within the try block (step S121: YES), the process proceeds to step S131. On the other hand, if the preventive evaluation necessity determination unit 214g-1 determines that the current position is not within the try block (step S121: NO), the process proceeds to step S141.

[0177] (Step S131) The bytecode inspection unit 214g decides whether or not to perform a precautionary evaluation at the current location to prevent overlooking any errors. After step S131, the information processing device 100 terminates the process shown in Figure 22.

[0178] (Step S141) Bytecode inspection unit 214g decides not to perform a precautionary evaluation at its current location. After step S141, the information processing device 100 terminates the process shown in Figure 22.

[0179] Figure 23 shows an example of the procedure for determining whether or not to perform a preventative evaluation at the current location to prevent false detections by the byte code inspection unit 214g. In step S111 of Figure 22, the byte code inspection unit 214g performs the process shown in Figure 23.

[0180] (Step S201) The branch search unit 214d-1 searches for conditional statements and loops after the current position and before the exception handling block. After step S201, the process proceeds to step S202.

[0181] (Step S202) The variable tracking unit 214c-1 within the exception handling block searches for variables that appear at the current position, looking at the data after the current position. After step S202, the process proceeds to step S203.

[0182] (Step S203) The preventative evaluation necessity determination unit 214g-1 determines whether there is an opportunity to evaluate the variable appearing at the current position after the current position and before the exception handling block. Specifically, the preventative evaluation necessity determination unit 214g-1 determines whether the variable appearing at the current position appears after the current position and before the exception handling block.

[0183] If the branch search unit 214d-1 detects a conditional statement or loop after the current position and before the exception handling block, the preventative evaluation necessity determination unit 214g-1 excludes the conditional statement or loop from the determination of whether or not the variable appearing at the current position has an opportunity to be evaluated. In other words, the preventative evaluation necessity determination unit 214g-1 determines whether or not the variable appearing at the current position has an opportunity to be evaluated within the range after the current position and before the exception handling block, and outside the conditional statement or loop. This corresponds to the processing in the fourth example described above. If the fourth example is not performed, the contents of the conditional statement and loop may be excluded from the determination by the bytecode inspection unit 214g.

[0184] If the preventative evaluation necessity determination unit 214g-1 determines that there is an opportunity to evaluate the variable appearing at the current position after the current position and before the exception handling block (step S203: YES), the process proceeds to step S211. On the other hand, if the preventative evaluation necessity determination unit 214g-1 determines that there is no opportunity to evaluate the variable appearing at the current position after the current position and before the exception handling block (step S203: NO), the process proceeds to step S221.

[0185] (Step S211) The prophylactic evaluation necessity determination unit 214g-1 decides not to perform a prophylactic evaluation at the current location. After step S211, the byte code inspection unit 214g completes the process shown in Figure 23.

[0186] (Step S221) The preventative evaluation necessity determination unit 214g-1 determines whether the variable appearing at the current position as a variable to be manipulated will be evaluated within the exception handling block. Specifically, the preventative evaluation necessity determination unit 214g-1 determines whether the variable appearing at the current position as a variable to be manipulated, or a variable whose value is obtained by referring to that variable, appears within the exception handling block.

[0187] If the preventative evaluation necessity determination unit 214g-1 determines that the variable currently appearing as the variable to be manipulated will be evaluated within the exception handling block (step S221: YES), the process proceeds to step S231. On the other hand, if the preventative evaluation necessity determination unit 214g-1 determines that the variable appearing at the current position as a variable to be manipulated will not be evaluated within the exception handling block (step S221: NO), the process proceeds to step S211.

[0188] (Step S231) The prophylactic evaluation necessity determination unit 214g-1 decides to perform a prophylactic evaluation at the current location. After step S231, the byte code inspection unit 214g completes the process shown in Figure 23.

[0189] The process in step S203 in Figure 23 corresponds to the process in the second example described above. If the second process is not performed, the process may always proceed to step S221 in step S203. The process in step S221 in Figure 23 corresponds to the process in the third example described above. If the third process is not performed, the process may always proceed to step S231 in step S222.

[0190] Figure 24 shows an example of the procedure for determining whether or not to perform a preventative evaluation at the current location to prevent overlooking any errors in the byte code inspection unit 214g. In step S131 of Figure 22, the byte code inspection unit 214g performs the process shown in Figure 24.

[0191] (Step S301) The branch search unit 214d-1 searches for conditional statements and loops after the current position and within try blocks. After step S301, the process proceeds to step S302.

[0192] (Step S302) The variable tracking unit 214c-1 within the exception handling block searches for variables that appear at the current position, after the current position and within the try block. After step S302, the process proceeds to step S303.

[0193] (Step S303) The preventative evaluation necessity determination unit 214g-1 determines whether there is an opportunity to evaluate the variable appearing at the current position after the current position and within the try block. Specifically, the preventative evaluation necessity determination unit 214g-1 determines whether the variable appearing at the current position appears after the current position and within the try block.

[0194] If the branch search unit 214d-1 detects a conditional statement or loop after the current position and within a try block, the preventative evaluation necessity determination unit 214g-1 excludes the conditional statement or loop from the determination of whether or not the variable appearing at the current position has an opportunity to be evaluated. In other words, the preventative evaluation necessity determination unit 214g-1 determines whether or not the variable appearing at the current position has an opportunity to be evaluated after the current position, within a try block, and outside the conditional statement or loop. This corresponds to the processing in the fourth example described above. If the fourth example is not performed, the contents of the conditional statement and loop may be excluded from the determination by the bytecode inspection unit 214g.

[0195] If the preventative evaluation necessity determination unit 214g-1 determines that there is an opportunity to evaluate a variable that appears at the current position later than the current position and within the try block (step S303: YES), the process proceeds to step S311. On the other hand, if the preventative evaluation necessity determination unit 214g-1 determines that there is no opportunity to evaluate a variable that appears at the current position if it is later than the current position and within the try block (step S303: NO), the process proceeds to step S321.

[0196] (Step S311) The prophylactic evaluation necessity determination unit 214g-1 decides not to perform a prophylactic evaluation at the current location. After step S311, the byte code inspection unit 214g completes the process shown in Figure 24.

[0197] (Step S321) The prophylactic evaluation necessity determination unit 214g-1 decides to perform a prophylactic evaluation at the current location. After step S321, the byte code inspection unit 214g completes the process shown in Figure 24.

[0198] The process in step S303 in Figure 24 corresponds to the process in the second example described above. If the second process is not performed, the process may always proceed to step S321 in step S303.

[0199] Figure 25 shows the 13th example of a source program that includes exception handling. In Figure 25, line numbers are shown on the left side of the source program. Lines 2 through 6 are examples of exception handling blocks. Of these, lines 2 through 3 are examples of try blocks, and lines 4 through 6 are examples of except blocks.

[0200] The third line, "df = pd.read_csv("file.csv")", indicates that the CSV file named "file.csv" will be read and assigned to the variable df. The "FileNotFoundError" on line 4 indicates that if a file not found exception occurs within the try block from lines 2 to 3, the code will execute the process shown in the except block from lines 4 to 6. Specifically, it will execute "print("Oops!")" on line 5. The "exit()" on line 6 corresponds to the end of the exception handling block. The "print(df)" on line 7 indicates that the value of the variable `df` will be output, such as by displaying its value.

[0201] Figure 26 shows an example of an assembly language-style representation of the converted bytecode of a source program. In Figure 26, lines 2 through 6 of the source program in Figure 25 are shown in assembly language-style converted bytecode. In Figure 26, the position (address) of the bytecode is indicated by the number of bytes to the left of the bytecode. Hereafter, this number will also be referred to as a label and will be used to specify the position in the bytecode. For example, the row showing "6" will also be referred to as label 6.

[0202] The bytecode acquisition unit 213 acquires the bytecode corresponding to lines 1 through 7 when the current position is line 3 in Figure 25. Specifically, the bytecode acquisition unit 213 acquires the stack frame immediately outside of read_csv in response to "read_csv" on line 3, and acquires the bytecode from the stack frame. In this case, in the bytecode of Figure 26, the current position is "CALL_METHOD" of label 14.

[0203] The bytecode inspection unit 214 refers to the bytecode in Figure 26 and detects "SET_FINALLY" at the position of label 6, which is before the current position, label 14, and determines that the current position is inside a try block. Furthermore, the bytecode inspection unit 214 detects "JUMP_IF_NOT_EXC_MATCH" at the position of label 26 and determines that the try block ends at the "JUMP_IF_NOT_EXC_MATCH" at the position of label 20, which is just before it. The bytecode inspection unit 214 determines that a preventative evaluation is necessary and sets a flag to indicate that a preventative evaluation should be performed at the current location (the flag is set).

[0204] Furthermore, the intermediate representation generation unit 212 generates an intermediate representation corresponding to the read_csv that appears at the current position. The evaluation unit 215 refers to the flag set by the bytecode inspection unit 214 and decides to perform the evaluation at the current position. Specifically, the evaluation unit 215 executes the intermediate representation generated by the intermediate representation generation unit 212, thereby reading the file using read_csv on the third line of Figure 25. Reading the file using read_csv and assigning it to the variable df is an example of evaluating the variable df.

[0205] In this way, variables appearing within a try block are evaluated within the try block. As a result, if an exception occurs during the evaluation of a variable, the code specified in the except block will be executed. In the examples shown in Figures 25 and 26, if the file named "file.csv" does not exist when reading the file using read_csv on the third line of Figure 25, the process shown in the except block from the fourth to the sixth line ("print("Oops!")" on the fifth line) will be executed. On the other hand, if a file named "file.csv" exists, the file is read successfully, and the read data is assigned to the variable df. As a result, the information processing device 100 completes the operation of the exception handling block from line 2 to line 6 in Figure 25 normally.

[0206] As described above, if the bytecode inspection unit 214 determines that the entire exception handling block is located further in the direction of program execution than the current position in program execution using the delayed evaluation method, or that the current position is located within the exception detection target portion (try block) of the exception handling block, it performs a process to detect the variable to be evaluated at the current position from the current position. The evaluation unit 215 evaluates the variable to be evaluated if it detects such a variable.

[0207] According to the information processing device 100, when a program is executed using delayed evaluation, exception handling can be performed in the same way as in the case of sequential execution. Specifically, the information processing device 100 can detect a situation where an entire exception handling block is located further in the direction of program execution than the current position, as a potential false detection scenario. The information processing device 100 then detects and evaluates variables that need to be evaluated from the current position, thereby preventing the exception handling from differing between delayed evaluation and sequential execution of the program due to false detections. Furthermore, the information processing device 100 can detect situations where the current position is within the exception detection target portion of the exception handling block as a potential scenario for overlooking an exception. The information processing device 100 then detects variables that need to be evaluated from the current position and performs the evaluation, thereby preventing differences in exception handling between delayed evaluation and sequential execution of the program due to overlooking an exception.

[0208] Further, the bytecode inspection unit 214 determines that the entire exception handling block is located on the program execution progress side from the current position, and the variable appearing at the current position as an operated variable appears on the program execution progress side from the current position and on the current position side from the start position of the exception handling block, then determines that the variable is excluded from evaluation at the current position. Further, the bytecode inspection unit 214 determines that the current position is located within an exception detection target part (try block) of the exception handling block, and the variable appearing at the current position as an operated variable appears on the program execution progress side from the current position and by the end position of the exception detection target part, then determines that the variable is excluded from evaluation at the current position.

[0209] According to the information processing apparatus 100, when there is an opportunity to evaluate a variable operated at the current position by a predetermined position on the program execution progress side from the current position, the evaluation of the variable can be delayed. By delaying the evaluation of the variable, the information processing apparatus 100 can increase the possibility of optimizing the intermediate representation related to the variable.

[0210] Furthermore, the bytecode inspection unit 214 determines that the entire exception handling block is located on the program execution progress direction side relative to the current position, a conditional statement or loop is located on the program execution progress direction side relative to the current position and on the current position side relative to the start position of the exception handling block, and a variable that appears at the current position as an operated variable appears on the program execution progress direction side relative to the current position, on the current position side relative to the start position of the exception handling block, and outside the conditional statement or loop, then the bytecode inspection unit 214 determines that said variable is excluded from evaluation at the current position. Furthermore, the bytecode inspection unit 214 determines that the current position is located within an exception detection target portion (try block) of the exception handling block, a conditional statement or loop is present between the current position and the exception detection target portion on the program execution progress direction side relative to the current position, and a variable that appears at the current position as an operated variable appears on the program execution progress direction side relative to the current position, up to the end position of the exception detection target portion, and outside the conditional statement or loop, then the bytecode inspection unit 214 determines that said variable is excluded from evaluation at the current position.

[0211] According to the information processing apparatus 100, conditional statements and loops can be excluded from objects for which opportunities to evaluate variables appearing at the current position are determined. In this respect, according to the information processing apparatus 100, the necessity of preventive evaluation can be determined with high accuracy.

[0212] Furthermore, the bytecode inspection unit 214 determines that the entire exception handling block is located on the program execution progress direction side relative to the current position, and a variable that appears at the current position as an operated variable does not appear within the exception handling block, then the bytecode inspection unit 214 determines that said variable is excluded from evaluation at the current position.

[0213] According to the information processing apparatus 100, when a variable appearing at the current position will not be evaluated within the exception handling block, the evaluation of said variable can be delayed. Delaying variable evaluation by the information processing apparatus 100 can increase the possibility of optimizing intermediate expressions related to said variable.

[0214] Furthermore, if the current position is within a function, the bytecode inspection unit 214 determines whether or not to detect a variable appearing at the current position as a variable to be evaluated at the current position, based on the program's direction of progress relative to the current position within that function, as well as the program's direction of progress relative to the function's caller.

[0215] According to the information processing device 100, the necessity of a preventative evaluation can be determined by also considering the caller of the function in which the current position is located. In this respect, the information processing device 100 can determine the necessity of a preventative evaluation with high accuracy.

[0216] Furthermore, the bytecode inspection unit 214 traces the function callers from the function where the current position is located up to the top-level function, and based on the program's progress direction relative to each caller, it decides whether or not to detect a variable appearing at the current position as a variable to be evaluated at the current position.

[0217] According to the information processing device 100, when function calls are nested, the need for preventative evaluation can be determined by considering the caller of each function. In this respect, the information processing device 100 can determine the need for preventative evaluation with high accuracy.

[0218] Furthermore, the bytecode inspection unit 214 detects a variable as the variable to be evaluated at the current position if a function call that takes a variable appearing at the current position as an argument is located further along the program execution path than the current position, and the function being called is not listed in the whitelist of functions that do not contain exception handling blocks.

[0219] According to the information processing device 100, it is possible to determine whether or not a preventative evaluation is necessary by considering whether or not the called function contains an exception handling block. In this respect, the information processing device 100 can determine whether or not a preventative evaluation is necessary with high accuracy. Furthermore, according to the information processing device 100, by using a whitelist, there is no need to analyze the contents of the called functions. According to the information processing device 100, in this respect, it is expected that the burden of determining whether or not a preventive evaluation is necessary will be small, and even when it is not possible to refer to the contents of the called functions, the necessity of a preventive evaluation can be determined with high accuracy.

[0220] Furthermore, the bytecode inspection unit 214 detects all variables being manipulated at the current position as variables to be evaluated at the current position. According to the information processing device 100, the necessity of a preventative evaluation can be determined by determining whether the entire exception handling block is located in the direction of program execution progress relative to the current position, or whether the current position is located within the exception detection target portion of the exception handling block. In this respect, the information processing device 100 is expected to have a low overhead in determining the necessity of a preventative evaluation.

[0221] <Second Embodiment> Figure 27 shows an example of the configuration of an information processing device according to at least one embodiment. In the configuration shown in Figure 27, the information processing device 610 includes a variable detection unit 611 and an evaluation unit 612.

[0222] In this configuration, if the variable detection unit 611 determines that the entire exception handling block is located in the direction of program execution relative to the current position in program execution using the delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, it performs a process to detect the variable to be evaluated at the current position from the current position. The evaluation unit 612 evaluates the variable to be evaluated if it detects such a variable. The variable detection unit 611 is an example of a variable detection means. The evaluation unit 612 is an example of an evaluation means.

[0223] According to the information processing device 610, when a program is executed using delayed evaluation, exception handling can be performed in the same way as in the case of sequential execution. Specifically, the information processing device 610 can detect a situation where the entire exception handling block is located further in the direction of program execution than the current position, as a potential false detection scenario. The information processing device 610 then detects and evaluates variables that need to be evaluated from the current position, thereby preventing the exception handling from differing between delayed evaluation and sequential execution of the program due to false detections. In this context, a false detection occurs when the evaluation of variables specified outside the try block (the exception detection target portion of the exception handling block) is performed within the try block.

[0224] Furthermore, the information processing device 610 can detect a situation where the current position is within the exception detection target portion of the exception handling block as a situation where an exception may be missed. The information processing device 610 then detects variables that need to be evaluated from the current position and performs the evaluation, thereby preventing the exception handling from differing between delayed evaluation and sequential execution of the program due to the occurrence of an missed exception. In this context, an missed exception refers to the evaluation of a variable specified in the try block occurring outside the try block.

[0225] <Third Embodiment> Figure 28 shows an example of processing in an information processing method according to at least one embodiment. The information processing method shown in Figure 28 includes detecting a variable (step S611) and evaluating the variable (step S612).

[0226] In detecting variables (step S611), if the computer determines that the entire exception handling block is located further in the direction of program execution than the current position in the program execution using the delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, it performs a process to detect the variable to be evaluated at the current position from the current position. In evaluating variables (step S612), the computer evaluates a variable if it detects one that needs to be evaluated.

[0227] According to the information processing method shown in FIG. 28, when a program is executed by lazy evaluation, exception handling can be performed in the same manner as in the case of sequential execution. Specifically, according to the information processing method shown in FIG. 28, a case where the entire exception handling block is located on the program execution progress side from the current position can be detected as a scene with a possibility of false detection. Further, according to the information processing method shown in FIG. 28, by detecting and evaluating a variable that needs to be evaluated from the current position, it is possible to prevent difference in exception handling between lazy evaluation and sequential execution of a program caused by occurrence of false detection. The false detection referred to herein means that a variable indicated outside a try block (a portion targeted for exception detection in an exception handling block) is evaluated inside the try block.

[0228] Further, according to the information processing method shown in FIG. 28, a case where the current position is located within the exception detection target portion of an exception handling block can be detected as a scene with a possibility of missed detection. Further, according to the information processing method shown in FIG. 28, by detecting and evaluating a variable that needs to be evaluated from the current position, it is possible to prevent difference in exception handling between lazy evaluation and sequential execution of a program caused by occurrence of missed detection. The missed detection referred to herein means that a variable indicated inside a try block is evaluated outside the try block.

[0229] FIG. 29 is a diagram showing an example of the configuration of a computer according to at least one embodiment. In the configuration shown in FIG. 29, a computer 700 includes a CPU 710, a main storage device 720, an auxiliary storage device 730, an interface 740, a non-volatile recording medium 750, and an accelerator 760.

[0230] One or more of the above-described information processing devices 100 and 610, or a part thereof, may be implemented in the computer 700. In that case, the operation of each processing unit described above is stored in the auxiliary storage device 730 in the form of a program. The CPU 710 and accelerator 760 read the program from the auxiliary storage device 730, expand it in the main memory 720, and execute the above-described processing according to the program. The CPU 710 also reserves memory areas in the main memory 720 corresponding to each of the above-described storage units according to the program. Communication between each device and other devices is performed by the interface 740 having a communication function and performing communication according to the control of the CPU 710. The interface 740 also has a port for the non-volatile recording medium 750 and reads information from the non-volatile recording medium 750 and writes information to the non-volatile recording medium 750.

[0231] When the information processing device 100 is implemented in the computer 700, the operation of the processing unit 190 and each of its parts is stored in auxiliary storage device 730 in the form of a program. The CPU 710 and accelerator 760 read the program from auxiliary storage device 730, load it into main memory device 720, and execute the above processing according to the program.

[0232] Furthermore, the CPU 710 reserves a memory area for the memory unit 180 in the main memory 720 according to the program. Communication with other devices by the communication unit 110 is performed by the interface 740 having a communication function and operating under the control of the CPU 710. Display of images by the display unit 120 is performed by the interface 740 having a display device and displaying various images under the control of the CPU 710. Acceptance of user operations by the operation input unit 130 is performed by the interface 740 having an input device and accepting user operations under the control of the CPU 710.

[0233] When the information processing device 610 is implemented in the computer 700, the operations of the variable detection unit 611 and the evaluation unit 612 are stored in auxiliary storage device 730 in the form of a program. The CPU 710 and accelerator 760 read the program from auxiliary storage device 730, load it into main memory 720, and execute the above processes according to the program.

[0234] Furthermore, the CPU 710 reserves memory in the main memory 720 for the information processing device 610 to perform processing according to the program. Communication between the information processing device 610 and other devices is performed by the interface 740 having a communication function and operating under the control of the CPU 710. Interaction between the information processing device 610 and the user is performed by the interface 740 having input and output devices, presenting information to the user via the output device and accepting user operations via the input device under the control of the CPU 710.

[0235] One or more of the above-mentioned programs may be recorded on the non-volatile recording medium 750. In this case, the interface 740 may read the program from the non-volatile recording medium 750. The CPU 710 and accelerator 760 may then either directly execute the program read by the interface 740, or temporarily save it in the main memory 720 or auxiliary memory 730 before executing it.

[0236] Alternatively, the processing of each part may be performed by recording a program for executing all or part of the processing performed by the information processing device 100 and the information processing device 610 on a computer-readable recording medium, and then loading and executing the program recorded on this recording medium into a computer system. The term "computer system" here includes hardware such as an operating system (OS) and peripheral devices. Furthermore, "computer-readable recording media" refers to portable media such as flexible disks, magneto-optical disks, ROMs (Read Only Memory), CD-ROMs (Compact Disc Read Only Memory), and storage devices such as hard disks built into computer systems. The above-mentioned program may be intended to implement only a part of the functions described above, and may also be able to implement the above-mentioned functions in combination with programs already recorded in the computer system.

[0237] Although the present disclosure has been described above with reference to embodiments, the present disclosure is not limited to the embodiments described above. Various modifications to the structure and details of the present disclosure can be made as understandable to those skilled in the art within the scope of the present disclosure. Furthermore, the embodiments described above may be combined with other embodiments as appropriate.

[0238] Some or all of the above embodiments may also be described as follows, but are not limited to the following:

[0239] (Note 1) If it is determined that the entire exception handling block is located in the direction of program execution relative to the current position in program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, a variable detection means performs a process to detect the variable to be evaluated at the current position from the current position. If a variable to be evaluated is detected, an evaluation means for evaluating that variable is provided. An information processing device equipped with the following features.

[0240] (Note 2) The variable detection means is If the entire exception handling block is located further in the direction of program execution than the current position, and if it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position, and further in the direction of program execution than the start position of the exception handling block than the current position, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further along the program execution direction from the current position up to the end position of the exception detection target portion, then that variable is excluded from evaluation at the current position. The information processing device described in Appendix 1.

[0241] (Note 3) The variable detection means is If the entire exception handling block is located further in the direction of program execution than the current position, and there is a conditional statement or loop further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and there is a conditional statement or loop between the current position and the exception detection target portion in the direction of program execution, and it is determined that a variable appearing at the current position as an manipulated variable appears outside the conditional statement or loop, up to the end position of the exception detection target portion in the direction of program execution, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. The information processing device described in Appendix 1.

[0242] (Note 4) The variable detection means is If the entire exception handling block is located further in the direction of program execution than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated does not appear within the exception handling block, then that variable is excluded from evaluation at the current position. An information processing device described in any one of the appendices 1 to 3.

[0243] (Note 5) The variable detection means, when the current position is located within a function, determines whether or not to detect a variable appearing at the current position as a variable to be evaluated at the current position, based on the program's direction of progress relative to the current position within that function, as well as the program's direction of progress relative to the caller of that function. An information processing device described in any one of the appendices 1 to 4.

[0244] (Note 6) The variable detection means traces the function callers from the function where the current position is located up to the highest-level function, and, based on the program's progress direction relative to each caller, determines whether or not to detect a variable appearing at the current position as a variable to be manipulated as the variable to be evaluated at the current position. The information processing device described in Appendix 5.

[0245] (Note 7) The variable detection means detects a variable as the variable to be evaluated at the current position if a function call that takes a variable appearing at the current position as an argument is located further along the program execution direction than the current position, and the called function is not listed in the whitelist of functions that do not include an exception handling block. An information processing device described in any one of the appendices 1 to 6.

[0246] (Note 8) The variable detection means detects all variables being manipulated at the current position as variables to be evaluated at the current position. The information processing device described in Appendix 1.

[0247] (Note 9) Computers If it is determined that the entire exception handling block is located in the direction of program execution relative to the current position in program execution using the delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, then the process of detecting the variable to be evaluated at the current position from the current position is performed. If a variable to be evaluated is detected, evaluate that variable. Information processing methods that include the following.

[0248] (Note 10) The detection process described above is performed by the computer, If the entire exception handling block is located further in the direction of program execution than the current position, and if it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position, and further in the direction of program execution than the start position of the exception handling block than the current position, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further along the program execution direction from the current position up to the end position of the exception detection target portion, then that variable is excluded from evaluation at the current position. The information processing method described in Appendix 9, including the above.

[0249] (Note 11) The detection process described above is performed by the computer, If the entire exception handling block is located further in the direction of program execution than the current position, and there is a conditional statement or loop further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and there is a conditional statement or loop between the current position and the exception detection target portion in the direction of program execution, and it is determined that a variable appearing at the current position as an manipulated variable appears outside the conditional statement or loop, up to the end position of the exception detection target portion in the direction of program execution, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. The information processing method described in Appendix 9, including the above.

[0250] (Note 12) The detection process described above is performed by the computer, If the entire exception handling block is located further in the direction of program execution than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated does not appear within the exception handling block, then that variable is excluded from evaluation at the current position. An information processing method described in any one of the appendices 9 to 11, including the above.

[0251] (Note 13) The detection process described above is performed by the computer, If the current position is located within a function, within that function, it is determined whether to detect a variable appearing at the current position as a variable to be evaluated at the current position, based on the program's direction of progress relative to the current position, as well as the program's direction of progress relative to the function's caller. An information processing method described in any one of the appendices 9 to 12, including the above.

[0252] (Note 14) The detection process described above is performed by the computer, The program traces the function calls from the function at the current position up to the top-level function, and based on the program's progress direction relative to each caller, it determines whether or not to detect a variable appearing at the current position as a variable to be evaluated at that position. The information processing method described in Appendix 13, including the above.

[0253] (Note 15) The detection process described above is performed by the computer, If a function call that takes a variable appearing at the current position as an argument is located further along the program execution path than the current position, and the called function is not listed in the whitelist of functions that do not contain exception handling blocks, then that variable is detected as the variable to be evaluated at the current position. An information processing method described in any one of the appendices 9 to 14, including the above.

[0254] (Note 16) The detection process described above is performed by the computer, All variables manipulated at the current position are detected as variables to be evaluated at the current position. The information processing method described in Appendix 9, including the above.

[0255] (Note 17) On the computer, If it is determined that the entire exception handling block is located in the direction of program execution relative to the current position in program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, then the process of detecting the variable to be evaluated at the current position from the current position is performed. If a variable to be evaluated is detected, evaluate that variable, A program that executes the command.

[0256] (Note 18) By performing the aforementioned detection process, the computer will If the entire exception handling block is located further in the direction of program execution than the current position, and if it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position, and further in the direction of program execution than the start position of the exception handling block than the current position, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further along the program execution direction from the current position up to the end position of the exception detection target portion, then that variable is excluded from evaluation at the current position. The program described in Appendix 17 that performs the action.

[0257] (Note 19) By performing the aforementioned detection process, the computer will If the entire exception handling block is located further in the direction of program execution than the current position, and there is a conditional statement or loop further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and there is a conditional statement or loop between the current position and the exception detection target portion in the direction of program execution, and it is determined that a variable appearing at the current position as an manipulated variable appears outside the conditional statement or loop, up to the end position of the exception detection target portion in the direction of program execution, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. The program described in Appendix 17 that performs the action.

[0258] (Note 20) By performing the aforementioned detection process, the computer will If the entire exception handling block is located further in the direction of program execution than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated does not appear within the exception handling block, then that variable is excluded from evaluation at the current position. A program described in any one of the appendices 17 to 19 that will perform the action.

[0259] (Note 21) By performing the aforementioned detection process, the computer will If the current position is located within a function, within that function, it is determined whether to detect a variable appearing at the current position as a variable to be evaluated at the current position, based on the program's direction of progress relative to the current position, as well as the program's direction of progress relative to the function's caller. A program described in any one of the appendices 17 to 20 that will perform the action.

[0260] (Note 22) By performing the aforementioned detection process, the computer will The program traces the function calls from the function at the current position up to the top-level function, and based on the program's progress direction relative to each caller, it determines whether or not to detect a variable appearing at the current position as a variable to be evaluated at that position. The program described in Appendix 21 that causes the action to be carried out.

[0261] (Note 23) By performing the aforementioned detection process, the computer will If a function call that takes a variable appearing at the current position as an argument is located further along the program execution path than the current position, and the called function is not listed in the whitelist of functions that do not contain exception handling blocks, then that variable is detected as the variable to be evaluated at the current position. A program described in any one of the appendices 17 to 22 that causes the action to be carried out.

[0262] (Note 24) By performing the aforementioned detection process, the computer will All variables manipulated at the current position are detected as variables to be evaluated at the current position. The program described in Appendix 17 that performs the action. [Explanation of symbols]

[0263] 100, 610 Information Processing Devices 110 Communications Department 120 Display section 130 Operation Input Section 180 Storage section 190 Processing Unit 210 Front End Section 211 Variable manipulation start section 212 Intermediate representation generator 213 Bytecode acquisition section 214, 214a, 214b, 214c, 214d, 214e, 214f, 214g Byte code inspection section 214a-1, 214e-1 Exception handling block search unit 214a-2, 214b-2, 214c-2, 214d-2, 214e-4, 214f-3, 214g-1 Preventive evaluation necessity determination unit 214b-1 Variable manipulation sequence tracking unit 214c-1 Variable tracking within exception handling block 214d-1 Branch Search Section 214e-2 Function return search section 214e-3 Stack frame upstream section 214f-1 Function Search Section 214f-2 Whitelist Storage Unit 215, 612 Evaluation Department 216 Variable operation termination section 220 Middleware Department 230 Backend Section 611 Variable detection unit

Claims

1. If it is determined that the entire exception handling block is located in the direction of program execution relative to the current position in program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, a variable detection means performs a process to detect the variable to be evaluated at the current position from the current position. If a variable to be evaluated is detected, an evaluation means for evaluating that variable is provided. An information processing device equipped with the following features.

2. The variable detection means is If the entire exception handling block is located further in the direction of program execution than the current position, and if it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position, and further in the direction of program execution than the start position of the exception handling block than the current position, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further along the program execution direction from the current position up to the end position of the exception detection target portion, then that variable is excluded from evaluation at the current position. The information processing apparatus according to claim 1.

3. The variable detection means is If the entire exception handling block is located further in the direction of program execution than the current position, and there is a conditional statement or loop further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated appears further in the direction of program execution than the current position and further in the direction of program execution than the start position of the exception handling block than the current position, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. If the current position is located within the exception detection target portion of the exception handling block, and there is a conditional statement or loop between the current position and the exception detection target portion in the direction of program execution, and it is determined that a variable appearing at the current position as an manipulated variable appears outside the conditional statement or loop, up to the end position of the exception detection target portion in the direction of program execution, and outside the conditional statement or loop, then that variable is excluded from evaluation at the current position. The information processing apparatus according to claim 1.

4. The variable detection means is If the entire exception handling block is located further in the direction of program execution than the current position, and it is determined that a variable appearing at the current position as a variable to be manipulated does not appear within the exception handling block, then that variable is excluded from evaluation at the current position. The information processing apparatus according to claim 1.

5. The variable detection means, when the current position is located within a function, determines whether or not to detect a variable appearing at the current position as a variable to be evaluated at the current position, based on the program's direction of progress relative to the current position within that function, as well as the program's direction of progress relative to the caller of that function. The information processing apparatus according to claim 1.

6. The variable detection means traces the function callers from the function where the current position is located up to the highest-level function, and, based on the program's progress direction relative to each caller, determines whether or not to detect a variable appearing at the current position as a variable to be manipulated as the variable to be evaluated at the current position. The information processing apparatus according to claim 5.

7. The variable detection means detects a variable as the variable to be evaluated at the current position if a function call that takes a variable appearing at the current position as an argument is located further along the program execution direction than the current position, and the called function is not listed in the whitelist of functions that do not include an exception handling block. The information processing apparatus according to claim 1.

8. The variable detection means detects all variables being manipulated at the current position as variables to be evaluated at the current position. The information processing apparatus according to claim 1.

9. Computers If it is determined that the entire exception handling block is located in the direction of program execution relative to the current position in program execution using the delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, then the process of detecting the variable to be evaluated at the current position from the current position is performed. If a variable to be evaluated is detected, evaluate that variable. Information processing methods that include the following.

10. On the computer, If it is determined that the entire exception handling block is located in the direction of program execution relative to the current position in program execution using a delayed evaluation method, or that the current position is located within the exception detection target portion of the exception handling block, then the process of detecting the variable to be evaluated at the current position from the current position is performed. If a variable to be evaluated is detected, evaluate that variable, A program that executes the command.

Images