On Saturday, March 26, 2011 1:50:40 PM UTC+1, Josh Berry wrote: > > I like how you call foul all the time on other people's rudeness, yet > feel free to call any design you don't care for silly on a whim. > Because I mean it. Given an API which as designed, returns void, but which needs to deal with errors (as I explained). Anybody that suggests the right way to return errors from this construct is by having a return value that needs to be inspected, especially if its banking stuff, is an idiot. I'll go to bat and defend my standpoint, but I doubt I have to. Are you honestly going to argue this?
TransferFunds could return any number of useful things, not the least > being a transferReceipt. > We have two options here: (A) *OTHER THAN* whether or not the transfer caused an error, this transferReceipt class contains no guaranteed important information; all it really is, other than relaying errors, is a way to inspect some specifics about the transfer, such as the exact bank account numbers and such. This is *HORRIBLE* design, as it becomes very very easy to forget to check for an error, at which point errors are just swallowed wholesale. Alternatively, perhaps you mean: (B) Error state is not the only crucial aspect of a transferReceipt; instead it contains vital information that e.g. needs to be written to the day's transaction receipt, or needs to be .confirm()ed or .apply()ed or some such. If it needs to be confirmed or applied, then those methods need to throw a (checked would be better than unchecked) exception, and you just moved the problem around, you did not solve it. If it now needs to be logged, the design is even more screwed up, as you should do these things in a single transaction and the source that caused an action should highly preferably be the one to log it. Either way I don't like this idea of returning a receipt with crucial information in it. Returning one with strictly non-crucial information in it is not just fine, it's a good idea. But errors are crucial and should this not be conveyed through it. > As for why one might prefer for this to be a > runtime, it is likely something you can let bubble up all the way to a > UI layer to have a handler that captures it and presents it to the > user in an appropriate fashion. The transactions should get rolled > back no matter what the actual exception was. > Sure, there are always scenarios where a seemingly appropriately checked exception ought to be bubbling up. That's kind of the point: If ALL checked exceptions should NEVER bubble then why use the exception mechanism to do it in the first place? The point is, there are many scenarios where just bubbling is not appropriate for this example, so the compiler forces you to acknowledge it. That's nice. Also, I linked to what I would consider a fairly elegant domain model > for trades. Not exactly the same, but pretty close. I am not looking > at it again right now, but I don't recall it relying on exceptions. > So now you moved the goalposts yet again and have changed the argument to: Give me an example of proper usage of checked exceptions on void methods, for some system where it is not possible to envision an alternative API that is not obviously inferior which does not use checked exceptions. I'm not playing this game. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
