Refcursor return set in plsql in oracle 10.2.0.4.0 db -

Question

I am writing a function which returns the result set to front end application. it all works fine for existing rec but it returs bad/awkward message when non exiting rec is given...
declare
user_cur SYS_REFCURSOR;
BEGIN
OPEN user_cur FOR
SELECT pwd,
first_name,
last_name
FROM XS_user
WHERE u_id = i_u_id;
FETCH user_cur
INTO l_pwd,
l_f_n
l_l_n
IF (user_cur%NOTFOUND)
THEN
---- return false ; -- does not work!!?!?
RAISE_APPLICATION_ERROR (-20001, 'No User Id ');
END IF;
return user_cur;
end;
i want to return result set when matching record found and need to return nothing when no record found.. but it says for nonexisting rec is
ORA-06503: PL/SQL: Function returned without value
ORA-06512: at "xxxx.xxx_xxx_xxx", line 353
ORA-06512: at line 1
Script Terminated on line 4.
I need into clause as i need to check other conditions on data
would you please suggest how to return nothing when no matching record found..?

Answer 1

knowledgespring wrote:
here is full picture of code i am writingSeveral problems with the code. There is not need for an explicit cursor, never mind a ref cursor. If you expect a single row, then code for that. More rows will be a fail. And that will raise an exception as it should. Exceptions are good.
Also be very careful with ref cursors. The PL/SQL engine does not close these cursor handles for you - so if you do not explicitly close ref cursors, your code will be leaking cursor handles and causing resource problems.
Also, do not code the same conditional processing structures again and again:
if db_pass!=pwd then
raise_application_error(-20001,'password wrong');
end if;Modularise it. Look again at the reference I posted in my previous response and at how the Assert() procedure is used to modularise such conditional processing blocks (and how error codes and messages are treated as data - as that is what they are).
And once modularised - easy to use. Easy to maintain. Easy to enhance. For example, you need to log application exceptions via an autonomous transaction to an error log table? A single change to the code is needed. Why? Because a single procedure is used to raise custom application errors. Instead of having to hunt through the type of code you've posted, looking for all the raise_application_error() calls scattered throughout the code.
The sample code I referred to shows exactly how requirements like yours should be addressed. Modularised code that is readable and maintainable with minimal effort.
It is one of the worse programming sins to approach a problem by not modularising. It is wrong to throw all the code into a single code unit and turning it into a complex and monolithic monster. And that is why your code does not work and are full of errors.
Keep it simple. Create simplistic building blocks, like Assert() and RaiseError() procedures. Then use these blocks to build a complex process. The end-result might be a complex process, but one that is easy to understand, take apart, re-assemble, modify, enhance and maintain, because it consists of simple building blocks.
And that is why software development is called software engineering. Basic engineering principles apply in writing robust and scalable software. Principles you can either take to heart and apply.. or not - and continue designing and writing software messes... (and I wish someone preached this to me as a junior programmer and I did not have to learn these lessons the hard way)