100501 non oracle,Error-100501 non-oracle exception

Well it's not true that the only way to cause 100501 is as they describe in their experience.

It's valuable to know about their experience but that's not the whole deal with this error.

Also I don't agree about when others then. but I'll let that slide....

I had my own battle with 100501 yesterday and it was caused by using :system.cursor_item in a when

new item instance trigger. Apparently there are cases where :system.cursor_item is off in the ozone and

following it e.g.

prev_field := get_item_property(:system.cursor_item,PREVIOUSITEM);

causes a runtime meltdown like I saw happen. Changing it to :system.trigger_item fixed it.

Note what the help system 11.1.1.4 says about this. Yet another error system.

How many are there? I would dearly love to see the code that could display every kind of error

that forms could detect. The vendor could make this easier if they corrected the "non-oracle" to

'java exception' which would point people more towards the solution. (Note since Java is from

oracle you can't say "non-oracle" regarding java. If java is tripping over your code you have yourself to blame now!)

Handling Java Exceptions from PL/SQL Code

The Java programming language uses the concept of exceptions to indicate that something has gone wrong while the program is executing. These types of exceptions are best thought of as something going wrong in the Java code itself.

The ORA_JAVA package provides you with the capability to work with Java exceptions as they are thrown in the Java code that is called from your Forms application. When a Java exception is thrown inside the Java code as it is being executed, Oracle Forms Server will detect this and will raise a PL/SQL exception called ORA_JAVA.EXCEPTION_THROWN. This PL/SQL exception can be detected using the standard PL/SQL exception handling mechanism. The Built-in ORA_JAVA.LAST_EXCEPTION can then be used to obtain a reference to the actual Java exception object that was thrown in the Java code. You should note that the Built-in returns a reference to the actual Java exception object that was thrown. You can use this exception object just as you would any other Java object you had created.

Note that if you do not add explicit exception handlers to your code, then these Oracle errors might be thrown instead of a named exception: ORA-105100—this is synonymous with ORA_JAVA.JAVA_ERROR ORA-105101—this is synonymous with ORA_JAVA.EXCEPTION_THROWN

Example

The following code sample demonstrates how to work with Java exceptions. The ORA_JAVA.EXCEPTION_THROWN PL/SQL exception is handled in the PL/SQL block. When this exception is detected, the actual Java exception is assigned to a local object. Using this object and the imported java.lang.Exception package, the getMessage Java method is invoked on the exception object to display the actual error that was detected.

DECLARE

exc ora_java.jobject;

. . .

BEGIN

[ do some operations ]

EXCEPTION

WHEN ORA_JAVA.EXCEPTION_THROWN THEN

exc := ORA_JAVA.LAST_EXCEPTION;

MESSAGE(Exception_.getMessage(exc));

ORA_JAVA.CLEAR_EXCEPTION;

END;

For the following example, the classes java.lang.Exception and java.lang.StringBuffer have been imported. Note that Exception has been imported as Exception_ because it is a PL/SQL reserved word.

DECLARE

buffer ORA_JAVA.JOBJECT;

newBuffer ORA_JAVA.JOBJECT;

javaException ORA_JAVA.JOBJECT;

BEGIN

buffer := StringBuffer.new('ABCDE');

-- This should raise an Index out of bounds error

-- as -1 is not a valid start point for the

-- Delete method

newBuffer := StringBuffer.Delete_(buffer,-1,2);

message(StringBuffer.toString(newBuffer));

EXCEPTION

WHEN ORA_JAVA.EXCEPTION_THROWN THEN

javaException := ORA_JAVA.LAST_EXCEPTION;

-- Print out the Exception by using the toString()

-- Method of the exception Object

message(Exception_.toString(javaException));

-- and clean up

ORA_JAVA.CLEAR_EXCEPTION;

END;