Design Questions about static factory classes
in [Java Programming]
|
From: Arne Vajhøj on 25 May 2010 21:17 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. Arne
From: Rhino on 26 May 2010 14:52 Lew <noone(a)lewscanon.com> wrote in news:hthjh6$m86$1(a)news.albasani.net: > Rhino wrote: >> 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. > > I recommend against popping a dialog or other window in a try/catch > block. > > Try/catch is for getting out of a mess. If there's a lot of code in > there, you risk getting in another mess. > > You also don't separate concerns enough, in this case the "happy-path" > logic from the error-message logic. > > Plus, your validation is likely, or should be likely to be off the > Event Dispatch Thread (EDT), since validation isn't really a graphic > action but a logical one. That involves thread coordination from > inside a try/catch, not so good. > > Let the catch block cause a return from the validator, and let the > caller of the validator decide where to go next. > Can you point me to any examples that show input error handling done right? I'm not following your proposal very clearly with just the English description; I need to see some code. Even though my code: a) works b) is very simple it is apparently not what the doctor ordered and I need to rethink yet another major aspect of my code.... -- Rhino
From: Rhino on 26 May 2010 14:54 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.... -- Rhino
From: Tom Anderson on 26 May 2010 15:03 On Tue, 25 May 2010, Arne Vajh?j wrote: > On 25-05-2010 01:05, Patricia Shanahan wrote: >> 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. > > That is a core problem of the domain logic exceptional criteria. If we > are in the low level API, then we don't have a clue about what is > exceptional. > > I would say that from a purity perspective "unknown" would favor return > value over exception, because I like the "convert return value to an > exception at a higher level" a lot more than the "convert exception to > return value at a higher level". Ah, whereas i'm just the opposite. It's easy to lose a return value. It's hard to lose an exception. tom -- uk.local groups TO BE RENAMED uk.lunatic.fringe groups
From: Patricia Shanahan on 26 May 2010 15:13
Tom Anderson wrote: > On Tue, 25 May 2010, Arne Vajh?j wrote: > >> On 25-05-2010 01:05, Patricia Shanahan wrote: >>> 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. >> >> That is a core problem of the domain logic exceptional criteria. If we >> are in the low level API, then we don't have a clue about what is >> exceptional. >> >> I would say that from a purity perspective "unknown" would favor >> return value over exception, because I like the "convert return value >> to an exception at a higher level" a lot more than the "convert >> exception to return value at a higher level". > > Ah, whereas i'm just the opposite. It's easy to lose a return value. > It's hard to lose an exception. Also, I prefer to reserve the return value for the primary result of the method, the value it will produce if everything goes right. For conversion methods, that is the result of a successful conversion. Although in many cases one could use e.g. null to indicate an error, that does not provide a good way of passing back the explanation of what went wrong. Patricia |