Getting Application Items to work with login

Question

I'm relatively new to Apex, so I've been creating numerous sample applications. In my latest one, I've been working on custom security schema and it's been working great for the most part. The one issue I'm having is passing login values into my application items. Though I don't receive any error messages or anything, upon checking the value of the application items via the session button, they never contain anything. The code I have in place on my login page is as follows:
begin
select username, user_id
into :F56_USER_NAME, :F56_USER_ID
from GS_USERS
where username = lower( rtrim( ltrim( :P101_USERNAME ) ) );
exception
when others then null;
end;
wwv_flow_custom_auth_std.login(
P_UNAME => :P101_USERNAME,
P_PASSWORD => :P101_PASSWORD,
P_SESSION_ID => v('APP_SESSION'),
P_FLOW_PAGE => :APP_ID
Does anybody know why or why not this wouldn't be working? I appreciate the help!

Answer 1

941907 wrote:
Prabodh wrote:
In all probability your PL/SQL block is raising an exception that you are unable to see because of your EXCEPTION section.
As has been advised by Joel, remove the EXCEPTION section and let the error propagate. At least you will see it and thus be able to address it.
Regards,Cheers, this was the solution. I was able to at least see the proper error and address it this way. The exception section I wrote was actually based on a tutorial online, so I'm curious as to why others use that if it's essentially of no use when errors arise. Regardless, my solution is fixed. Thanks!Good question: I guess it comes down to your acceptance of Rumsfeld doctrine. IMO there are potentially places where you can legitimately use the "WHEN OTHERS" exception clause e.g. if you want to quietly capture an exception and not have it bubble all the way up to the user interface in an uncontrolled manner.
That is predicated on these conditions:
1. You have already attempted to anticipate and handle (where appropriate) "known" exceptions first e.g. a no_data_found exception in conjunction with a SELECT ... INTO statement
2. Your program/application is able to gracefully deal with "unknown unknown" exceptions or is otherwise unaffected
3. You record the mystery exception in some meaningful manner (e.g. a debug log) that will allow you to trace it back to source
The above conditions being true are usually quite rare though. Even then, I would be wary of using it in a very low-level routine as the deeper an exception occurs (and is captured), the less context you have to describe what happened. If I ever use this clause, its near the "top" of my code (indeed, often only in Apex Page/Application Process level).
It's worth taking 5-10 minutes to have a read through the exception handling advice in the PL/SQL Language reference.