Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged


With no other context: Neither. The correct place to put the catch is "at the point where something useful can be done about the failure". This is not the same as needing to add try-finally or try-with-resource around potentially throwing methods, which obviously can only go where the things they refer to are.


Inheritance is not bad per se. It depends on how you use it. Avoiding a technique just because someone says it is bad is not a good way to make decisions. While I see where Josh Bloch is coming from, the alternative he proposes is not quite the same thing. The Template pattern aims to enforce a particular design; it takes advantage of the rigidity of ...


I'd be inclined to split the responsibilities into two: creating and sending emails, loosely coupled with an Email interface. Then the EmailService takes the simple form you intuitively want and the implementation is only dependent on the transportation infrastructure. public interface EmailService { void send(Email email) throws X; } Whilst an ...


In my opinion is the EmailService implementation is way to broad, it will be a great idea to split it into more specific implementations (like you did). the interface-segregation principle states: ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of ...


Your ResourceCommonProcedures doesn't really seem to be an example of the Template Method pattern (as it doesn't really define a 'template' for an operation, except perhaps in a trivial sense). Your base class acts as a factory that produces a concrete ResourceCommonProcedures-derived instance based on an identifying parameter (resourceType). Arguably, that ...


I assume you mean Method2 calls Method1 (as currently written Method2 calls itself recursively). You can put the catch-block in either place, depending on what you intend to do about the exception (and there are many possible ways in which an exception can be responded to). There is no general answer in the abstract.


Don't catch an exception if you can't (or until you can) do something useful about it. There will be exceptions which you can't do anything about. There will be exceptions which you haven't thought about. Those kinds of exceptions are often critical or fatal. Exceptions like that are rare in a well-developed application. But, you certainly want to know ...


One of the strong selling points of OO is supposed to be encapsulation: the implementation details are hidden away and only API, in the form of method signatures and the like, are exposed to the wider world. Yet there is a well recognised way of breaking that encapsulation: you guarantee that a method will perform certain actions, including calling other - ...

Only top voted, non community-wiki answers of a minimum length are eligible