Design Questions about static factory classes
in [Java Programming]
|
From: Tom Anderson on 24 May 2010 08:29 On Sun, 23 May 2010, Arne Vajh?j wrote: > 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: >>>> >>>>> 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. Shocking. 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: Arne Vajhøj on 24 May 2010 20:15 On 24-05-2010 08:12, Tom Anderson wrote: > 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. It is always good to read opinions from qualified people even if you disagree with them. > >> 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? If it is interactive user input then the overhead of exceptions will be unmeasurable due the ratio between CPU speed and human typing speed. I don't think performance is the best argument against exceptions for bad user input. >> 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. You are free to have your opinion - just note that a lot of people disagree today. Arne
From: Patricia Shanahan on 25 May 2010 01:05 Arne Vajh�j wrote: .... > 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. .... Reading these two paragraphs, I think the difference between us is the viewpoint we use in evaluating "exceptional". You seem to be using a whole program viewpoint. I look at it much more locally. Typically, in my code, a String conversion method has no idea whether the String it is converting came from a GUI TextField, an input file edited by a user, or a file that was generated automatically. Its design cannot and should not depend on whether an inability to do the conversion is due to an error in a user input or in a system generated input. Instead, I look at the issue from the point of view of the method I'm defining. What is the primary function of this method? If its primary job is conversion of a String to some other type of value, and it cannot do it because of incorrect content in the String, it throws an exception. Of course, somewhere in the call stack there is a method that does know where the unconvertible String came from. If the condition is not exceptional from its point of view, it should catch the exception and take appropriate action. Patricia
From: Tom Anderson on 25 May 2010 08:30 On Mon, 24 May 2010, Arne Vajh?j wrote: > On 24-05-2010 08:12, Tom Anderson wrote: >> 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. > > It is always good to read opinions from qualified people even > if you disagree with them. True. But i don't have that book, and i'm not about to rush out and buy it because it contains advice i disagree with! If i come across a copy of it (i might be able to borrow one from the tribe upstairs at some point), i will certainly read this. >>> 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? > > If it is interactive user input then the overhead of exceptions > will be unmeasurable due the ratio between CPU speed and human > typing speed. > > I don't think performance is the best argument against exceptions > for bad user input. Needless to say! >>> 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. > > You are free to have your opinion - just note that a lot > of people disagree today. I certainly recognise that. And am used to it :). tom -- Vive la chimie, en particulier, et la connaissance en general. -- Herve This
From: Rhino on 25 May 2010 12:02
Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bf9d9b9$0$272$14726298(a)news.sunsite.dk: > On 23-05-2010 20:26, Rhino wrote: >> On May 22, 7:38 pm, Arne Vajh�j<a...(a)vajhoej.dk> wrote: >>> On 22-05-2010 15:05, Rhino wrote: >>> >>> >>> >>>> Arne Vajh�j<a...(a)vajhoej.dk> wrote in >>>>> I think it depends a lot of the context you develop software in. >>> >>>>> Global or local development? >>> >>>>> global => do development in English >>>>> local => pick English or local language as you prefer >>> >>>>> Are you developing single-customer project-style software or >>>>> multi-customer product-style software? >>> >>>>> product => internationalize, have English and then add to >>>>> supported languages as customers require them (note that >>>>> customers can want 3 things A) English version, B) local >>>>> version C) Choice of English for local for end users >>> >>>>> project => whatever the customer wants >>> >>>>> And then we have not even talked about interesting countries >>>>> like Belgium and Switzerland with multiple official languages >>>>> (Canada is easier because one of the languages is English). >>> >>>>> That is not a clear answer, but it is a complex question! >>> >>>> It certainly is. I'm trying to write code that will be easily >>>> usable by non-English speakers. But my code isn't actually being >>>> written for a specific customer at this time, other than me. At the >>>> moment, I'm trying to put together a sort of code portfolio. I'm >>>> hoping it will show prospective employers or clients that I am >>>> culturally sensitive enough to write code that will work in >>>> multiple languages and knowledgeable on how to do it. In other >>>> words, I don't just want to claim that I am culturally sensitive >>>> but then have no code to back that up. When they challenge me >>>> to prove that I can write code that works for customers in various >>>> locales, I want to be able to point them to some decent examples >>>> where I have done that. I'm just trying to figure out the best way >>>> to do that right now..... >>> >>> Do you just want to support western languages? >>> >>> Or do you also want to solve the difficult problems? >>> >>> >>> >>>>> That problem is not so important. You would not want to display >>>>> Java exception text to end-users anyway. >>> >>>> Really? I find that a surprising thing to say. Maybe we're not >>>> talking about the same thing. >>> >>>> 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'm not disagreeing with you but isn't there some leverage to be >> obtained from using the same message to do both: inform the user of a >> problem and write it to the log if it is sufficiently severe? >> >> I suppose you would argue that the two cases are mutually exclusive: >> any situation serious enough to justify a log message would generate >> its message in an entirely different way (from a different place) >> than a "user error" message.... >> >> So, am I safe in assuming that serious developers are generating >> "user messages", like bad input on a form, from ResourceBundles and >> "serious" errors for logs and such things from some other source, >> perhaps hard-coded within the class itself? > > In most cases I don't think the exception text would > tell the end user anything. > > Let us say that you have developed an accounting program and > the code throws an exception telling that it could not > load the JDBC driver. > > No point in telling an accountant that. He don't know what > JDBC is. > > You tell the accountant that there were a configuration error > and that he should contact his IT department. > > You write in the log file what the problem is and when IT > support look at the log file, then they know what the > problem is. > > Of course there are cases where the message text from the > exception can be used in the end user error text. Just don't > display class names, stack traces etc.. > I completely agree with your argument in this scenario. I was thinking more of cases where user input is faulty and could be corrected by the user. For instance, I have a little GUI-based "color converter" class: it has an input field where I type the hex representation of a Color, e.g. FFCC00, and it gives me the RGB representation, e.g. 25, 204, 0, in another field when I click on the Convert button. Now, if the user mistypes the hex reprsentation of the color, say FFCCZZ, the method that does the conversion detects that ZZ is not a valid hex representation of the Blue component of a Color, throws an IllegalArgumentExpection with text to that effect (the message is retrieved from a ResourceBundle to allow for internationalization) and then the try/catch block in the ColorConverter class displays that message in a JOptionPane so that the user knows what to fix. I don't log any of this and certainly don't show the user anything like a stacktrace; just the message from the ResourceBundle. That's a reasonable approach, isn't it? -- Rhino |