[maverick-devel] [ maverick-Bugs-529777 ] ICONV croaks on invalid data

[SourceForge.net <no...@so...>]

Bugs item #529777, was opened at 2002-03-14 08:14
Message generated for change (Comment added) made by rjc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102228&aid=529777&group_id=2228

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Clint Byrum (cbyrum)
Assigned to: Clint Byrum (cbyrum)
Summary: ICONV croaks on invalid data

Initial Comment:
This code:

A="ABC"
PRINT ICONV(ABC,"MR2")

Generates this exception:

Exception in thread "main"
java.lang.NumberFormatException: ABC
        at java.lang.Integer.parseInt(Integer.java:414)
        at java.math.BigInteger.<init>(BigInteger.java:316)
        at java.math.BigInteger.<init>(BigInteger.java:445)
        at java.math.BigDecimal.<init>(BigDecimal.java:158)
        at
org.maverickdbms.basic.mvBasicString.getBigDecimal(Unknown
Source)
        at
org.maverickdbms.basic.mvConstantString.ICONV(Unknown
Source)
        at T5.run(T5.BAS:2)
        at T5.main(T5.BAS:1)

My solution is to simply catch all
NumberFormatExceptions in ICONV() and set the result to
null(as in zero-length-string). I'd love to get
everybody's opinion on this, and maybe some people
testing the above code on their various platforms to
see what they return. Please discuss on the list. :D

----------------------------------------------------------------------

>Comment By: Robert Colquhoun (rjc)
Date: 2005-04-12 01:45

Message:
Logged In: YES 
user_id=11445

Fixed as a compiler define:
org.maverickdbms.tools.basic_conv_null={true, false}

basic_conv_null = true
On error return an empty string.

basic_conv_null = false
On error return the input string

Also should set STATUS() on error, but this is at the moment
sometimes a bit inconsistent(Should be filed as separate
bugs for individual cases where STATUS is not set).


----------------------------------------------------------------------

Comment By: Robert Colquhoun (rjc)
Date: 2002-03-16 01:41

Message:
Logged In: YES 
user_id=11445

<I>1) CONV_NULL was more an exersize for me than a real
solution. I think it needs to be a compile time option also.
Seeing as we have no facilities for that, I think we need to
discuss it outside just the scope of this bug.</I>

Have a look in org.maverickdbms.tools.BasicConstants, the
compile time options are defined there.  The $OPTION stuff
is almost there in DefineFilterStream, really just need a
list of options to support.


<I>2) Lets not cater to platforms, but rather behaviors. We can
then produce documentation that tells users how to make the
system perform things the way system X does.</I>

Ok.

<I>3) For this bug, I'd like to catch the exception and do
something semi-sane anyways. Uncaught exceptions like this
are, IMO, a very bad thing. Should we, however, print out a
"non numeric where numeric expected" error?</I>

What do other systems do in the same situation?  If they
have a runtime abort, then us throwing an exception in the
same circumstance is not too bad.  If they trap the error
though we shoulds trap the error as well.

<I>3a) Whats more "correct"? Returning a "null",
or returning
the passed in string?</I>

I <B>>think</B> universe uses null as a default, perhaps the
INFO.CONVERT $OPTION to alter.  Unidata returns the input
param by default(can be altered with some UDT.OPTION).


----------------------------------------------------------------------

Comment By: Clint Byrum (cbyrum)
Date: 2002-03-15 18:18

Message:
Logged In: YES 
user_id=11247

Ok, a few things then.

1) CONV_NULL was more an exersize for me than a real
solution. I think it needs to be a compile time option also.
Seeing as we have no facilities for that, I think we need to
discuss it outside just the scope of this bug.

2) Lets not cater to platforms, but rather behaviors. We can
then produce documentation that tells users how to make the
system perform things the way system X does.

3) For this bug, I'd like to catch the exception and do
something semi-sane anyways. Uncaught exceptions like this
are, IMO, a very bad thing. Should we, however, print out a
"non numeric where numeric expected" error?

3a) Whats more "correct"? Returning a "null", or returning
the passed in string?

----------------------------------------------------------------------

Comment By: Robert Colquhoun (rjc)
Date: 2002-03-14 13:04

Message:
Logged In: YES 
user_id=11445

Sorry for the delay in posting about the ICONV/OCONV stuff
have been busy on other things...

I think the ICONV example above will sometimes require to
return the original string ie in Prime type mode, and
sometimes  a zero length string ie Pick type mode.

For the same problem with OCONV you added a runtime property
CONV_NULL to switch between the 2 modes.   I think this
needs to be changed to a compile time option otherwise you
might  be in a situation when using programs from different
sources of having Program A require CONV_NULL set one way
and Program B the opposite.

If CONV_NULL becomes a basic compiler property(....do other
MV versions have anything similar, a $OPTION perhaps?) there
will need to be 2 OCONV and 2 ICONV functions in the basic
librarys ie ICONV_Pick(), ICONV_Prime(), OCONV_Pick() and
OCONV_Prime().  Alternatively a flag parameter can be passed
into the ICONV and OCONV functions to determine the behaviour.

One other alternative solution i have been planning for some
time is to move the ICONV/OCONV functionality out of the
mvConstantString class and into a separate formatter class
similar to java.text.NumberFormat/java.text.DateFormat etc
in the java standard library.  The formatters would come
from the factory class and would simplify the calling
params, as well a been able to be cached.

PS there are some ICONV/OCONV tests in test/java/string,
which i have been meaning for sometime to turn into a proper
junit test suite.

 - Robert

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102228&aid=529777&group_id=2228