Well you could argue that using when others to say a value isn't a date is a bit dangerous too ;)
e.g. if there's an IO error or some other exception unrelated to date conversion, you'll be told it's not a date, even if it is...
12.2 has a couple of alternatives (see review above). Before then you could avoid the inlining issue by returning the date if you can convert it and null otherwise:
ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL';
ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL = 3;
ALTER SESSION SET PLSQL_CODE_TYPE = 'NATIVE';
CREATE OR REPLACE PROCEDURE RAGTEST
AS
FUNCTION is_nls_date
( p_string IN VARCHAR2
, p_format_mask IN VARCHAR2
)
RETURN DATE
AS
l_return date;
format_mismatch exception;
pragma exception_init ( format_mismatch, -1861);
BEGIN
BEGIN
l_return := TO_DATE(p_string, ''''||p_format_mask||'''');
EXCEPTION
WHEN format_mismatch THEN
l_return := null;
END;
--
RETURN l_return;
END is_nls_date;
BEGIN
DBMS_OUTPUT.PUT_LINE('is_date 01.01.xxxx = '||is_nls_date('01.01.xxxx','DD.MM.YYYY'));
DBMS_OUTPUT.PUT_LINE('is_date 01.01.2001 = '||is_nls_date('01.01.2001','DD.MM.YYYY'));
END;
/
sho err
LINE/COL ERROR
-------- -----------------------------------------------------------------
1/1 PLW-05018: unit RAGTEST omitted optional AUTHID clause; default value DEFINER used
3/5 PLW-06006: uncalled procedure "IS_NLS_DATE" is removed.
23/5 PLW-06005: inlining of call of procedure 'IS_NLS_DATE' was done
23/51 PLW-06025: implicit use of NLS session parameters may be a security risk
24/5 PLW-06005: inlining of call of procedure 'IS_NLS_DATE' was done
24/51 PLW-06025: implicit use of NLS session parameters may be a security risk
exec ragtest;
is_date 01.01.xxxx =
is_date 01.01.2001 = 01-JAN-2001 00:00:00