On Fri, Mar 25, 2011 at 10:57 AM, Reinier Zwitserloot <[email protected]> wrote: > How did I 'screw with quote trees'? All my quotations have been in order and > from a single post. You did not elaborate on either > InvocationTargetExceptions or InsufficientFundsException anywhere in your > response, but you did ask me again to list examples. What did I miss?
Apologies, I shouldn't have accused you of messing with the quote tree. Odds are much more likely you just weren't considering the subjects nearly as linearly as I was. (That is, the "topic" of this part of my quote was specifically where I was asking for void methods that throw exceptions that aren't typically treated as a runtime one.) > InvocationTargetException is an exception in the standard runtime libraries. > Invoking methods and constructors via reflection can cause this to be > thrown. It indicates that the invocation worked just fine, but the thing you > invoked threw an exception. While technically Method.invoke() does return > something (Object, to be precise), if the author of the invoke call (thinks > he) knows that the method doesn't return anything anyway, why would he check > it? In many circumstances it walks, quaks, and looks like a > duch^H^H^H^Hvoid-returning method. It's an example that essentially fits > your requirement of an example a checked exception thrown by a > void-returning method that seems like decent API. See, I don't think I've ever seen someone using reflection to call a method where they had a legitimate response that wasn't to first simply log it, grab the wrapped exception and rethrow that. Indeed, the very existance of InvocationTargetException is something I've often seen lead to errors, as people mistakenly rethrow that, and not the exception that it wraps. > Is this a no true scotsman argument, or did we just move on to: Okay, there > _ARE_ examples of decent usage of Checked Exceptions, but I just feel there > aren't enough of them to warrant all the pain. Which is a fine position to > take, just be aware that there's an inherent "personal taste" aspect to such > a claim. What? My claim here is you can not say that an Exception makes a better checked exception than a runtime one without knowing the API in which it is used. Essentially, I can't say one way or another about whether or not the FundsException should be checked or not. I can say that I'd probably rather the information it provides be provided through an Either return than a checked exception. You then claimed that there is no good api around the Either and related types. I provided an API example that I thought fit that bill rather nicely. -- 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.
