On Thu, Sep 23, 2010 at 10:21 PM, Miroslav Pokorny < miroslav.poko...@gmail.com> wrote:
> So in other words by statement that developers dont want to deal with > excecptions because its more work is right ? and since most libraries throw > lots of exceptions using them because a game of catch this here, handle that > there which makes it difficult or a pain. With such cases handling checked > cases in a general manner means one needs to handle Exception which is not > the best idea in the end. In the end its easier to let some top level > handler to catch Throwable and log. If you want to sum it up by "more work," sure. I meant more that it is simply not appropriate at the level most APIs expose exceptions. Perhaps if I could just mark a class as "pretty much all methods can throw this exception." :) Consider, when you put a beam in a house, did you make sure you account for "NotEnoughSupportException" at each beam? I would argue that is a concern that is tackled at a much more holistic nature than the act of setting a specific piece of wood. This is no different than making a function call. If you can reduce your program down to a single point of coordination between your code and another piece, it makes sense. Otherwise, not so much. As you add in more and more coordinating pieces, the odds that the specific point of failure can act appropriately to fix the problem drops considerably. (Otherwise, we'd have self charging batteries whenever they hit "LowChargeException.") I suspect I am just getting too lured into the "actor" style of everything being asynchronous and am really just blaming all of this on how reliant we are on "stack traces." -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
