In my opinion I don't think that the message level should be lower than 25 unless debugging.That is the most dangerous thing I have seen in a long time! What if the form starts failing for a user, yet there is no error message to report? With the proper on-error message handling, it can save you hours helping the user get back up and running. Our most troublesome is the FRM-40735 -- it hides security errors, for example when the user does not have access granted to a particular table. (Check the processing for that error in the PLL_On_Error process I provided in the link above).
The constant barrage of messages that oracle likes to put up is insane.Well, I can understand that statement. But early on, we started out setting Message_Level to 5. But then we developed the PLL_On_Message procedure below to filter the "informative" messages, and continued on to add the PLL_On_Error in the link I posted above. With those in place, and with Message Level set to zero, we now get ONLY the messages one might want.
PROCEDURE PLL_ON_MESSAGE (MSGN_IN IN NUMBER DEFAULT NULL, MSG_IN IN VARCHAR2 DEFAULT NULL) IS --* -- PLL_On_Message can be called by a form's On-Message trigger, --* -- which fires whenever an "Informative" Type forms message is -- issued by the form. It displays the message, but the -- no_acknowledge parameter prevents it from popping up in an alert -- box if there is another message following. -- MSG_VAL NUMBER := NVL(MSGN_IN,MESSAGE_CODE); MSG VARCHAR2(150) := NVL(MSG_IN,SUBSTR(' '||MESSAGE_TYPE||'-' ||TO_CHAR(MSG_VAL)||': '||MESSAGE_TEXT,1,150)); BEGIN IF MSG_VAL = 40350 --Query caused no records to be retrieved. -- Trap all 'informative' messages resulting from post, commit, -- and commit following post. OR MSG_VAL BETWEEN 40400 AND 40407 THEN NULL; ELSE MESSAGE(MSG,NO_ACKNOWLEDGE); END IF; END PLL_ON_MESSAGE;