Bugzilla – Full Text Bug Listing
| Summary: | Expecting TypeCastException when intialize a date with an invalid string value | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Kathy Carroll <carrollk> | ||||
| Component: | EDT | Assignee: | Project Inbox <edt.javagen-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jeffdouglas, mheitz | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Fixed in EString.asString(Calendar). Needed to move code inside a try block, and make it throw the proper kind of exception from its catch block. verified Fails now with install build 201110110900 Created attachment 205033 [details]
Additional Variations
Attached related eunit test variations. Run RunAllTests_pgms
I don't see any error here, other than the expectation in the testcase.
actual timestamp("yyyyMMddHHmmss") = "65*10*31*10*35*55";
That is a valid date - year = 65, etc
The Calendar object in javagen reports it as valid, that is why there is no exception thrown
65 is not a valid year. ETimestamp.asTimestamp(EString,EString) says "Years must be represented with four digits". If you really want 65 A.D. then the string must start with 0065. The code for this checking came from RBD. Are you saying that this will give an error in RBD? I'm going to update the runtime code for both EDate and ETimestamp to throw an exception if exactly 4 digits are not given for the year. Does that match the spec? Implemented the check for both date and timestamp forcing 4 digits for the year if the year is specified Response to comment 7: I don't think it would be an error in RBD, but we're not trying to keep the same behavior in this case. Response to comments 8 and 9: What you've done does not match the spec for EDate.asDate(EString). "The year requires a minimum of one digit." (Why is date flexible but timestamp is strict? Because dates are much more likely to be entered by a user.) I backed out the code so now date can allow less than 4 digits for the year. This makes timestamp and date inconsistent, but that seems to be what is wanted. Verified 201110271153 & closed. My original issues have been resolved to my satisfaction. After reading comment 11, I decided to add a couple of variations to EString009. I am not getting what I desired. However, it isn't clear from EString.egl what will be appended to the two digit year. 00? 19? 20? (In reply to comment #12) Any digits not supplied default to zero. "10" is the year 10, not 1910 or 2010. No Y2K bugs for us! |
program drive type BasicProgram {} function main() creation(); creationFails(); end function creation() // This should work try expecting string = "06/28/1969"; qDay date = expecting; actual string = qDay; If (actual == expecting) syslib.writeStdOut("MM/DD/YYYY Equal"); else syslib.writeStdout("MM/DD/YYYY Actual/Expecting Different Defect 355782"); syslib.writeStdout(actual); syslib.writeStdout(expecting); end onException(oops TypeCastException) Syslib.writeStdOut(" Can't create date using MM/DD/YYYY"); end end function creationFails() // this shouldn't work try expecting string = "19690628"; qDay date = expecting; actual string = qDay; If (actual == expecting) syslib.writeStdOut("YYYYMMDD Equal"); else syslib.writeStdout("YYYYMMDD Different"); end onException(oops TypeCastException) Syslib.writeStdOut(" Correctly can't create date using YYYYMMDD"); onException (oops AnyException) if ( oops isa JavaObjectException) objEx JavaObjectException = oops as JavaObjectException; SysLib.writeStdout(" Got an unexpected exception JavaObjectException " + objEX.exceptionType) ; else SysLib.writeStdout(" Got an unexpected exception") ; end end end end