Design Questions about static factory classes
in [Java Programming]
|
From: Arne Vajhøj on 23 May 2010 23:24 On 23-05-2010 20:32, Rhino wrote: > On May 23, 7:18 am, Tom Anderson<t...(a)urchin.earth.li> wrote: >> On Sat, 22 May 2010, Arne Vajh?j wrote: >>> On 22-05-2010 15:05, Rhino wrote: >> >>>> I'm thinking of a situation like completing a form in a GUI. The >>>> customer has to enter his date of birth. Let's say that I can't use a >>>> JSpinner for some reason; it can't do everything I need it to do. The >>>> customer is given a simple JTextField for entering a date. Clearly, the >>>> customer would have many opportunities to enter bad data. He could type >>>> in 1985- 15-31 when he meant to type 1985-05-01; the first value is >>>> obviously a bad date since there are only 12 months in the year, not >>>> 15. My practice is to write edits that check for that kind of mistake >>>> and generate an exception, typically IllegalArgumentException, with a >>>> clear error message that reminds the user that there is no such month >>>> as '15'. Naturally, the customer might not be an English speaker so I >>>> put all such messages in ResourceBundles so that other bundles can >>>> easily be added for any languages that I support. >> >>>> How would you handle such a situation? >> >>> Catch the exception but display something else that the exception text. >> >>> Exceptions texts are for log files to be handed over to developers. >> >>> For user input I don't even think that you should throw an exception. >>> Maybe just test and tell the user to correct. >> >>> Bad user input is not really exceptional enough to justify an exception. >> >> I disagree. We've had arguments about the proper use of exceptions on this >> newsgroup before, so i recognise that this is a matter where opinions >> vary, but exceptions seem like a perfectly acceptable option for dealing >> with bad user input to me. They might not be the right solution in every >> situation, but they are an option that can be considered. .... > I'm glad you jumped in on this point, Tom. I thought for a second that > opinions were united on the idea that exceptions had no place in > notifying users about "user errors" (as opposed to "system errrors"). > That's a "good news, bad news" scenario as I see it: if everyone > agreed how to do it, it would be up to me to conform with the > concensus and I wouldn't have to think about what should be done very > much. But if there are different schools of thought on the issue, I > could show any reasonable approach in my "code portfolio" and still be > okay, although I might have to be able to defend whatever approach I > used against the other approaches..... It will not get you thrown out the door. But if the call stack between throw and catch is less than 2 levels, then I would consider it bad style. Much better with something that test and return true or false. Arne
From: Patricia Shanahan on 23 May 2010 23:33 Arne Vajh�j wrote: > On 23-05-2010 20:32, Rhino wrote: >> On May 23, 7:18 am, Tom Anderson<t...(a)urchin.earth.li> wrote: >>> On Sat, 22 May 2010, Arne Vajh?j wrote: >>>> On 22-05-2010 15:05, Rhino wrote: >>> >>>>> I'm thinking of a situation like completing a form in a GUI. The >>>>> customer has to enter his date of birth. Let's say that I can't use a >>>>> JSpinner for some reason; it can't do everything I need it to do. The >>>>> customer is given a simple JTextField for entering a date. Clearly, >>>>> the >>>>> customer would have many opportunities to enter bad data. He could >>>>> type >>>>> in 1985- 15-31 when he meant to type 1985-05-01; the first value is >>>>> obviously a bad date since there are only 12 months in the year, not >>>>> 15. My practice is to write edits that check for that kind of mistake >>>>> and generate an exception, typically IllegalArgumentException, with a >>>>> clear error message that reminds the user that there is no such month >>>>> as '15'. Naturally, the customer might not be an English speaker so I >>>>> put all such messages in ResourceBundles so that other bundles can >>>>> easily be added for any languages that I support. >>> >>>>> How would you handle such a situation? >>> >>>> Catch the exception but display something else that the exception text. >>> >>>> Exceptions texts are for log files to be handed over to developers. >>> >>>> For user input I don't even think that you should throw an exception. >>>> Maybe just test and tell the user to correct. >>> >>>> Bad user input is not really exceptional enough to justify an >>>> exception. >>> >>> I disagree. We've had arguments about the proper use of exceptions on >>> this >>> newsgroup before, so i recognise that this is a matter where opinions >>> vary, but exceptions seem like a perfectly acceptable option for dealing >>> with bad user input to me. They might not be the right solution in every >>> situation, but they are an option that can be considered. > ... >> I'm glad you jumped in on this point, Tom. I thought for a second that >> opinions were united on the idea that exceptions had no place in >> notifying users about "user errors" (as opposed to "system errrors"). >> That's a "good news, bad news" scenario as I see it: if everyone >> agreed how to do it, it would be up to me to conform with the >> concensus and I wouldn't have to think about what should be done very >> much. But if there are different schools of thought on the issue, I >> could show any reasonable approach in my "code portfolio" and still be >> okay, although I might have to be able to defend whatever approach I >> used against the other approaches..... > > It will not get you thrown out the door. But if the call stack between > throw and catch is less than 2 levels, then I would consider it > bad style. Much better with something that test and return true > or false. That tends to lead to very artificial handling of the result of the input processing. To me, it makes a lot of sense to have a conversion method that normally returns the converted value, and throws an exception if it cannot do so because of an error in the data it is converting. Patricia
From: Arne Vajhøj on 23 May 2010 23:44 On 23-05-2010 23:33, Patricia Shanahan wrote: > Arne Vajh�j wrote: >> On 23-05-2010 20:32, Rhino wrote: >>> On May 23, 7:18 am, Tom Anderson<t...(a)urchin.earth.li> wrote: >>>> On Sat, 22 May 2010, Arne Vajh?j wrote: >>>>> On 22-05-2010 15:05, Rhino wrote: >>>> >>>>>> I'm thinking of a situation like completing a form in a GUI. The >>>>>> customer has to enter his date of birth. Let's say that I can't use a >>>>>> JSpinner for some reason; it can't do everything I need it to do. The >>>>>> customer is given a simple JTextField for entering a date. >>>>>> Clearly, the >>>>>> customer would have many opportunities to enter bad data. He could >>>>>> type >>>>>> in 1985- 15-31 when he meant to type 1985-05-01; the first value is >>>>>> obviously a bad date since there are only 12 months in the year, not >>>>>> 15. My practice is to write edits that check for that kind of mistake >>>>>> and generate an exception, typically IllegalArgumentException, with a >>>>>> clear error message that reminds the user that there is no such month >>>>>> as '15'. Naturally, the customer might not be an English speaker so I >>>>>> put all such messages in ResourceBundles so that other bundles can >>>>>> easily be added for any languages that I support. >>>> >>>>>> How would you handle such a situation? >>>> >>>>> Catch the exception but display something else that the exception >>>>> text. >>>> >>>>> Exceptions texts are for log files to be handed over to developers. >>>> >>>>> For user input I don't even think that you should throw an exception. >>>>> Maybe just test and tell the user to correct. >>>> >>>>> Bad user input is not really exceptional enough to justify an >>>>> exception. >>>> >>>> I disagree. We've had arguments about the proper use of exceptions >>>> on this >>>> newsgroup before, so i recognise that this is a matter where opinions >>>> vary, but exceptions seem like a perfectly acceptable option for >>>> dealing >>>> with bad user input to me. They might not be the right solution in >>>> every >>>> situation, but they are an option that can be considered. >> ... >>> I'm glad you jumped in on this point, Tom. I thought for a second that >>> opinions were united on the idea that exceptions had no place in >>> notifying users about "user errors" (as opposed to "system errrors"). >>> That's a "good news, bad news" scenario as I see it: if everyone >>> agreed how to do it, it would be up to me to conform with the >>> concensus and I wouldn't have to think about what should be done very >>> much. But if there are different schools of thought on the issue, I >>> could show any reasonable approach in my "code portfolio" and still be >>> okay, although I might have to be able to defend whatever approach I >>> used against the other approaches..... >> >> It will not get you thrown out the door. But if the call stack between >> throw and catch is less than 2 levels, then I would consider it >> bad style. Much better with something that test and return true >> or false. > > That tends to lead to very artificial handling of the result of the > input processing. To me, it makes a lot of sense to have a conversion > method that normally returns the converted value, and throws an > exception if it cannot do so because of an error in the data it is > converting. But when it is user input, then it is really not that exceptional with format errors. If it was reading a file that was generated by a system, then I would consider a format error exceptional. Even for unexceptional stuff an exception can be practical to roll back the call stack, but if that is not the case either, then I don't consider exception attractive. A very good example is that .NET in 1.1->2.0 supplemented the int.Parse method with a new int.TryParse method - today the later is used in >90% of all cases. Arne
From: Tom Anderson on 24 May 2010 08:12 On Sun, 23 May 2010, Lew wrote: > Arne Vajh?j wrote: >>> Bad user input is not really exceptional enough to justify an exception. > > Tom Anderson wrote: >> I disagree. We've had arguments about the proper use of exceptions on >> this newsgroup before, so i [sic] recognise that this is a matter where >> opinions vary, but exceptions seem like a perfectly acceptable option >> for dealing with bad user input to me. They might not be the right >> solution in every situation, but they are an option that can be considered. > > And usually rejected. > > Read /Effective Java/ (2nd ed.), "Item 57: Use exceptions only for > exceptional conditions", and the rest of section 9. No. > Part of the problem with exceptions is that they are expensive relative > to conditionals. True. I wouldn't worry about that in input validation code of this kind unless i had a profiler screaming at me that it was a problem. Hmm. Do profilers track the amount of time the JVM spends handling exceptions? > The other part in this case is that you expect bad inputs - they aren't > exceptional conditions at all. > > Your style is your style, tom, and you are absolutely correct to suggest that > one should consider all options. But the design purpose of exceptions is to > deal with out-of-line conditions, and input validation is squarely in line. I don't agree that bad input is not an exceptional condition; i wonder if you are confusing 'exceptional' and 'unlikely' or 'unexpected'. I agree that validating input must be done inline, but not that dealing with invalid input must be. I'd say exactly the opposite, in fact. tom -- The exact mechanics are unknown, but a recent sound file revealed the process to go something like this: WONKA WONKA WONKA WONKA DEOO DEOO DEOO DEOO WOWOWOWOWOWOWOWOWOWOWOW WONKA WONKA WONKA...
From: Tom Anderson on 24 May 2010 08:15
On Sun, 23 May 2010, Arne Vajh?j wrote: > On 23-05-2010 20:18, Rhino wrote: >> On May 23, 6:35 pm, Arne Vajh?j<a...(a)vajhoej.dk> wrote: >>> On 23-05-2010 17:33, Rhino wrote: >>> >>>> Tom Anderson<t...(a)urchin.earth.li> wrote in >>>>> And then deploy the JAR and reboot. Not so hot if you're hoping to run >>>>> a global ecommerce site. >>> >>>> I didn't realize you needed to reboot to get the new Jar to take effect. >>>> That's lousy. Isn't it possible to simply refresh the new Jar in place >>>> without rebooting? I'm pretty sure Tomcat lets you redeploy a Jar without >>>> stopping Tomcat first but my Tomcat skills are rusty so I may be >>>> wrong.... >>> >>> If you can discard the classloader, then you can do that instead >>> of restarting the JVM. >>> >>> But it is still an interruption of production. >>> >>> In tomcat that is what happens when you restart just the app >>> and not the entire server. >> >> Whatever happened to the time-honoured tradition of maintenance >> windows? I don't think I've ever heard of a system that was truly 24 x >> 7. All of them used to have scheduled downtimes (or at least the >> option of having downtimes as needed) for things like taking backups >> and so forth. Do real-life Internet online systems _really_ promise 24 >> x 7? Don't the executives and/or lawyers build in at least some >> provisions for downtime into their contracts? >> >> I'm sure that people buying systems push for those downtimes to be as >> brief and infrequent as possible but surely their must be _some_ >> provision for it in web-based systems? Or am I behind the times? > > It depends on the context. > > For many internal systems then nightly downtime is still > acceptable. > > But the world has become global. It is always work hours > somewhere on the planet. > > Public internet systems like Google and FaceBook does > not close a couple of hours every day. > > Huge multinational corporations with offices in almost > all timezones can not shutdown business critical system > a couple of hours every day. > > Nightly downtime still exists but it is definitely > out of fashion today. > > Many business system still have weekly/monthly > scheduled downtime though. > > But Google/FaceBook types does not even have that. We're no Google, and we will have downtime when we do need to update the code. But pushing new content may well be happening on a daily basis, and we don't want daily maintenance outages. Mind you, if you have a cluster of app servers, you can update the code on a machine-by-machine basis without ever taking the whole cluster down. Provided you don't change the interface between machines, that is. I anticipate that we'd be able to do this, althoug whether it'll be considered worth setting up to avoid a few minutes of downtime, i don't know. tom -- The exact mechanics are unknown, but a recent sound file revealed the process to go something like this: WONKA WONKA WONKA WONKA DEOO DEOO DEOO DEOO WOWOWOWOWOWOWOWOWOWOWOW WONKA WONKA WONKA... |