What if a function doesn't return a value, and expected to hang.

Question

Hi, i'm using D2K, 6i forms.
i've a function something like this:
/* Function returns current slno for a transaction.
create or replace function gen_auto_slno_fn
(doc_vr varchar2,
branch_vr varchar2)
return varchar IS
genslno VARCHAR2(15) ;
BEGIN
BEGIN
SELECT lpad((nvl(SLNO,0)+1),5,0)
INTO genslno
FROM GEN_SLNO
WHERE doc_name = doc_vr
AND BRANCH_CODE=branch_vr;
return(genslno);
EXCEPTION
WHEN no_data_found then
Dbms_output.put_line('No data found in General Serial number for '||doc_vr);
raise_application_error(-20100,sqlerrm);
END;
END;
My problem is:
suppose if such branch_code does not exist, then
it will go exception part.
I was expecting the 'No data ...error message ' in my forms.
but Instead of that a message such as 'Unhandled exception occurs.
I also tried returning a value like :
EXCEPTION
WHEN no_data_found then
Dbms_output.put_line('No data found in General Serial number for '||doc_vr);
return('ERROR');
--raise_application_error(-20100,sqlerrm);
END;
It was working then.
My question is: how do I display the whole error message on my form and raise form_trigger_failure ?
( also the one in the subject line!)
Message was edited by:
abhijithdev

Answer 1

A comment on using exception handlers and raising exceptions.
WHEN no_data_found then
  Dbms_output.put_line('No data found in General Serial number for '||doc_vr);
  raise_application_error(-20100,sqlerrm); DBMS_OUTPUT is superfluous and meaningless in production code. It should not be there... and if debugging is required, then it is easy to make it vastly superior than the very primitive DBMS_OUTPUT interface.
Ditto for RAISE_APPLICATION_ERROR. Calling this system procedure directly, does not support logging and tracing and troubleshooting and debugging problems.
One of the basic (I would call it the very most basic) rules in software development is to modularise. This includes wrapping system calls into wrappers - that allows additional flexibility and makes maintenance and development a lot easier.
Instead of calling RAISE_APPLICATION_ERROR, create a wrapper PL/SQL procedure called something like RaiseException().
Input parameters would typically be an error message number. The message for the error can also be passed.. though I prefer to have a message array (static PL/SQL var) that can be used to lookup the error message for that error code.
As all exceptions are now raised via a single proc that you control, you can easily add debug information to it. Log the exception (using an autonomous transaction) in a log table. Add the PL/SQL call stack to the message. Write an error to the alert log for those real critical fubar errors. Call DBMS_OUTPUT if need be. Even send the error message to a DBMS_PIPE for an error console to pick up and display interactively.
Designing and coding wrappers for system calls are a critical cornerstone of an application that is flexible and easy to maintain and extend.