object relational database versus "inteligent" serialization
in [Java Programming]
|
From: Pitch on 10 Feb 2010 11:06 In article <hkufjt$u3l$1(a)news.eternal-september.org>, esosman(a)ieee-dot- org.invalid says... > How can the superclass' constructor validate its inputs > if the subclass has somehow substituted its own code so the > superclass' constructor never even runs? True. Actually this is the same problem as passing invalid arguments. The caller must be carefull, and yes, the caller is to blame. > > Yes, I see the smiley, but even so I don't think you Get It. > Here's a toy class: > > class Toy { > private final ToyBox box; > Toy(ToyBox whereItBelongs) { > box = whereItBelongs); > } Well, if I pass here null you'll still get an error. :( So throwing ISE here or throwing NPE later is more or less the same. -- stirr your cofee properly
From: Lew on 10 Feb 2010 13:08 esosman(a)ieee-dot-org.invalid says... >> Yes, I see the smiley, but even so I don't think you Get It. >> Here's a toy class: >> >> class Toy { >> private final ToyBox box; >> Toy(ToyBox whereItBelongs) { >> box = whereItBelongs); >> } Pitch wrote: > Well, if I pass here null you'll still get an error. :( > So throwing ISE here or throwing NPE later is more or less the same. Nope. If the NPE is thrown in the constructor, as it should be, then you get it before you obtain a valid object, at the exact point where the problem occurred. If the NPE is thrown in the 'takeOutAndPlayWith()' method, it's happening much later and far removed from the failure point. Not even close to the same. -- Lew
From: Tom Anderson on 10 Feb 2010 13:35 On Tue, 9 Feb 2010, Arne Vajh?j wrote: > On 09-02-2010 13:12, Tom Anderson wrote: >> On Mon, 8 Feb 2010, Arne Vajh?j wrote: >> >>> On 08-02-2010 02:09, luc peuvrier wrote: >>>> On 8 f?v, 04:23, Lew<no...(a)lewscanon.com> wrote: >>>>> Lew wrote: >>>>>> just between us, after 30 years of programming I have never handled >>>>>> monetary data: surprise, right? >>>>> >>>>>> I am really happy to learn than float is not proper. >>>>> >>>>> Think about the reasons why. >>>> >>>> Luc: >>>> float is an approximate numeric datatype, as defined by ANSI >>>> standards. >>>> http://stackoverflow.com/questions/285680/representing-monetary-values-in-java: >>>> >>>> "Martin Fowler recommends the implementation of a dedicated Money >>>> class to represent currency amounts, and that also implements rules >>>> for currency conversion." >>> >>> That is one option. >>> >>> java.math.BigDecimal may be good enough for many cases. >> >> Or int/long and establishing a convention that you're working in pence, >> or thousandths of a dollar, or whatever is suitable. > > Yes, but why bother when BigDecimal already handle it. Because you can say + to an int. tom -- It's rare that you're simply presented with a knob whose only two positions are "Make History" and "Flee Your Glorious Destiny." -- Tycho Brahae
From: Mike Schilling on 10 Feb 2010 13:42 Tom Anderson wrote: > > Because you can say + to an int. Why, so can I, or so can any man; But will they overflow when you do add them?
From: Tom Anderson on 10 Feb 2010 16:28
On Wed, 10 Feb 2010, Mike Schilling wrote: > Tom Anderson wrote: > >> Because you can say + to an int. > > Why, so can I, or so can any man; But will they overflow when you do add > them? My dear fellow, i have an investment scheme that is literally banking on it! Longs might be a better choice for general currency purposes - they'd handle up to 92 petapounds on a penny basis, and i'd feel fairly confident that no actual currency amount would exceed that. A programming language which handles integer overflow sensibly (by throwing an exception) would be another. tom -- william gibson said that the future has already happened, it just isn't evenly distributed. he was talking specifically about finsbury park. -- andy |