Design Questions about static factory classes
in [Java Programming]
|
From: Rhino on 23 May 2010 20:18 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. > > Arne 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? -- Rhino
From: Rhino on 23 May 2010 20:26 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?
From: Rhino on 23 May 2010 20:32 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. > > Of course, i wouldn't show the exception's error message to the user. An > approach i've seen is to do something like: > > public class ValidationException extends Exception { > private final String validationKey; > private final Object[] parameters; > public ValidationException(String validationKey, Object.. parameters) { > super(format(validationKey, Locale.getDefault())); > this.validationKey = validationKey; > this.parameters = parameters; > } > public String format(Locale locale) { > return format(validationKey, locale); > } > private static String format(String validationKey, Locale locale) { > ResourceBundle bundle = ResourceBundle.getBundle("ValidationMessages", locale); > String pattern = bundle.getString(validationKey); > MessageFormat fmt = new MessageFormat(pattern, locale); > return fmt.format(parameters); > } > > } > > ValidationExceptions have a message in the language of the default locale > (or you could hardcode this to english if you wanted), which can be used > in logging and so on, but can also supply their message in other > languages, as needed. > > If you put on a getter for the fields, then code that handles them can > also act on the key and parameters in other ways, as appropriate, if > simply printing the messasge is not adequate. Although in this case, you > should probably be using subclasses rather than switching on the contents > of the key. If you do subclass, you can refine the above approach by > pushing the parameters down into subclasses, accessed via an abstract > getParameters method in the base class. That lets you construct the array > on the fly from meaningful fields: > > public class AgeTooYoungException extends ValidationException { > private final int actualAge; > private final int requiredAge; > // constructor > protected Object[] getParameters() { > return new Object[] {actualAge, requiredAge}; > } > // getters > > } > > Code which catches this and is interested in the ages can then discover > them via proper getter calls, rather than having to scrub about in an > untyped parameter array. > > Another refinement is to add a field which somehow indicates which bit of > user input was wrong - a simple string key might be enough. The UI code > can then attach the error message to the right bit of the UI simply by > matching that up. > 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.....
From: Arne Vajhøj on 23 May 2010 21:08 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. Arne
From: Arne Vajhøj on 23 May 2010 21:43
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.. Arne |