Sorry i was using recovery as a way to group possible actions to a problem- different word same desired outcome.
On Saturday, March 26, 2011 2:54:53 PM UTC+11, Cédric Beust ♔ wrote: > > > > On Fri, Mar 25, 2011 at 8:39 PM, mP <[email protected]> wrote: > >> True its important to know if a remote method call failed because of >> networking issues, but once we know by catching theres not much we can do to >> recover > > > On the contrary, there are plenty of things you can do, among which 1) > retry according to certain policies (e.g. exponential back off), 2) let the > user know, 3) log it, 4) fail, 5) try again on a different cluster node, > etc... > > I smell a remote ejb stub :) In practical terms end developers never try any of these simply because the API does not present an opportunity to retry on a different cluster node simply because they are not aware of the available nodes. When working w/ remote services throwing RE becomes another problem that can happen at any time like OOME and for the sake of simplicity it probably makes sense to group it as such. A lot of Springy ppl and users seem to think this way and its got a lot going for it. > > >> , which makes it seem more like an environmental/runtime problem than >> something that can be reattempted. >> >> Isnt it fair to say checkness should be equivalent to the ability to >> recover > > > No, it's broader than that: the point of checked exceptions is that you can > do *something* about it, not necessarily limited to recovering. > > -- > Cédric > > > -- 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.
