Design Questions about static factory classes
in [Java Programming]
|
From: David Lamb on 26 May 2010 17:08 On 21/05/2010 7:16 PM, Rhino wrote: > Also, is there much need for systems in which the user can switch > languages on the fly? Yes, if only for testing. You don't want to have to exit the program, change locale, and re-run it to verify that your other-language text comes out OK.
From: Rhino on 26 May 2010 17:54 Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bfc7466$0$280$14726298 @news.sunsite.dk: > On 25-05-2010 14:57, Rhino wrote: >> But I'd like to try to sum up a bit now. The conversation has gotten >> sufficiently fragmented that I'm not sure what we would all agree on >> with regards to the situation I am trying to resolve. > >> However, I find myself seriously doubting that Locale SHOULD be a >> class variable after all. And if my reasoning is sound, which I hope >> you will tell me, I may be able to go back to having all the methods >> be static. >> >> As I look at the classes in the Java API, only a tiny handful of them >> have constructors that take a Locale as an argument and only a tiny >> handful have setLocale methods. Assuming that the Java API is >> considered well-designed by the Java community - and I have to hope it >> is :-) - that tells me that the remaining 99.9% of classes are >> expecting to provide any locale-specific information in only ONE >> Locale. > > Note that the Java API is a low level API and localization is > most relevant for higher level business app code. > > The huge majority of Java API classes does not have any > need for localization at all. > Good point. > >> Furthermore, no class invoking the API is typically going to >> want to get the information in more than one language at a go. >> Essentially, the classes operate on the basis of the Locale defined by >> the user.country and user.language properties. Therefore, if my >> properties are set to English and Canada, that is the locale that the >> JVM is going to try to find - of course it will settle for other >> flavours of English if there is no specific en_CA resource bundle - >> and use for any other locale-specific text. (DateFormats, >> NumberFormats, and their kin handle the localization needs of those >> special kinds of data.) >> >> Providing a way to set a specific Locale and even to change that >> Locale on the fly so that classes could potentially invoke the class >> repeatedly for different Locales is simply overbuilding and is almost >> certainly not necessary at all! (I say 'almost' in deference to Lew's >> observations about there being no hard and fast rules, which makes a >> lot of sense to me.) So I think I can dispose of Locale in >> constructors (and their associated getInstance() methods altogether. >> Likewise, I can omit and setLocale() and/or getLocale() methods from >> my utility classes too. Methods that seek to get ResourceBundles will >> simply seek them for the default Locale, as determined via >> Locale.getDefault(). > > That strategy may work OK for fat client apps. It will not work > well for the server side code in web apps. > So where does it leave me with my utility classes? Some of the methods in these classes are just convenience methods and others do smallish tasks like counting the number of occurrences of a given character in a string. It's certainly possible that some will get bad input and that they will correspondingly need to handle them some way. Should I be giving users of these classes the ability to specify a non-default locale and/or switch to a different locale on the fly? If not, I'm inclined to just let them work with the default locale and retrofit additional constructors and/or getLocale()/setLocale() later if the need arises.... -- Rhino
From: Arne Vajhøj on 26 May 2010 20:30 On 26-05-2010 14:54, Rhino wrote: > Arne Vajh�j<arne(a)vajhoej.dk> wrote in > news:4bfc7690$0$278$14726298(a)news.sunsite.dk: > >> On 25-05-2010 12:02, Rhino wrote: >>> Arne Vajh�j<arne(a)vajhoej.dk> wrote in >>>> 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? >> >> It is an OK approach. >> >> A possible alternative could be to throw a custom exception >> NotHexColorStringException and let the exception handling >> code read the localized text. >> > Okay, I'll give that some thought. > > But it sounds like you are saying that this is not the routine or best > way to handle input errors so maybe I need to imitate the better > approaches. If someone could point me to examples of good input error > handling, maybe I could finally see how I'm supposed to be doing it.... I am just reluctant to rely too much on the message of an Exception. I prefer to rely on the type of the Exception. Arne
From: Patricia Shanahan on 26 May 2010 21:27 Arne Vajh�j wrote: > On 26-05-2010 14:54, Rhino wrote: >> Arne Vajh�j<arne(a)vajhoej.dk> wrote in >> news:4bfc7690$0$278$14726298(a)news.sunsite.dk: >> >>> On 25-05-2010 12:02, Rhino wrote: >>>> Arne Vajh�j<arne(a)vajhoej.dk> wrote in >>>>> 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? >>> >>> It is an OK approach. >>> >>> A possible alternative could be to throw a custom exception >>> NotHexColorStringException and let the exception handling >>> code read the localized text. >>> >> Okay, I'll give that some thought. >> >> But it sounds like you are saying that this is not the routine or best >> way to handle input errors so maybe I need to imitate the better >> approaches. If someone could point me to examples of good input error >> handling, maybe I could finally see how I'm supposed to be doing it.... > > I am just reluctant to rely too much on the message of an Exception. I'm particularly dubious about this in connection with internationalization, because in some cases logging should be in the developers' working language, but GUI display in a language chosen by the end user. The same Exception might trigger either or both. > > I prefer to rely on the type of the Exception. Also remember that you can add your own fields to an Exception subclass. I don't know whether this makes sense, but for a String conversion exception it might be helpful to include the index in the String of the first error. I'm not sure whether it would ever make sense to add an enum for more detailed classification - one could always subclass instead. Patricia
From: Arne Vajhøj on 26 May 2010 22:06
On 26-05-2010 21:27, Patricia Shanahan wrote: > Arne Vajh�j wrote: >> On 26-05-2010 14:54, Rhino wrote: >>> Arne Vajh�j<arne(a)vajhoej.dk> wrote in >>> news:4bfc7690$0$278$14726298(a)news.sunsite.dk: >>> >>>> On 25-05-2010 12:02, Rhino wrote: >>>>> Arne Vajh�j<arne(a)vajhoej.dk> wrote in >>>>>> 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? >>>> >>>> It is an OK approach. >>>> >>>> A possible alternative could be to throw a custom exception >>>> NotHexColorStringException and let the exception handling >>>> code read the localized text. >>>> >>> Okay, I'll give that some thought. >>> >>> But it sounds like you are saying that this is not the routine or best >>> way to handle input errors so maybe I need to imitate the better >>> approaches. If someone could point me to examples of good input error >>> handling, maybe I could finally see how I'm supposed to be doing it.... >> >> I am just reluctant to rely too much on the message of an Exception. > > I'm particularly dubious about this in connection with > internationalization, because in some cases logging should be in the > developers' working language, but GUI display in a language chosen by > the end user. The same Exception might trigger either or both. > >> >> I prefer to rely on the type of the Exception. > > Also remember that you can add your own fields to an Exception subclass. > > I don't know whether this makes sense, but for a String conversion > exception it might be helpful to include the index in the String of the > first error. I'm not sure whether it would ever make sense to add an > enum for more detailed classification - one could always subclass instead. SQLException has a getErrorCode. But then the original design of only having SQLException class was a rather big mistake. Which they tried to fix in 1.6. Arne |