Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Interfaces and exceptions, best practice question

Reply
Thread Tools

Interfaces and exceptions, best practice question

 
 
Jama
Guest
Posts: n/a
 
      06-02-2006

Greetings,

When I build my libraries, I code to interfaces, which is clearly a
best practice. When programmers then create classes that use my
interfaces, they complain that the exceptions they want to throw are
not defined in my signature. For example:

public interface myInterface {
public void instantiateThisMethod();
}

is no good. People want interfaces like:

public interface myInterface {
public void instantiateThisMethod() throws Exception;
}

This gives the implementing programmer flexibility to throw any
exception they want. So now, all my interfaces have "throws Exception"
tacked on the end of every signature.

Is this a bad idea? What's the proper approach to defining exception
handling with interfaces from a best practices point of view?

Thanks,
J

 
Reply With Quote
 
 
 
 
=?ISO-8859-15?Q?Tobias_Schr=F6er?=
Guest
Posts: n/a
 
      06-02-2006
Hi,

Jama schrieb:
> Greetings,
>
> When I build my libraries, I code to interfaces, which is clearly a
> best practice. When programmers then create classes that use my
> interfaces, they complain that the exceptions they want to throw are
> not defined in my signature. For example:
>
> public interface myInterface {
> public void instantiateThisMethod();
> }
>
> is no good. People want interfaces like:
>
> public interface myInterface {
> public void instantiateThisMethod() throws Exception;
> }
>
> This gives the implementing programmer flexibility to throw any
> exception they want. So now, all my interfaces have "throws Exception"
> tacked on the end of every signature.
>
> Is this a bad idea? What's the proper approach to defining exception
> handling with interfaces from a best practices point of view?


IMO, throws Exception is not a very good practise. It forces you to
explicitly catch all Exceptions, including RuntimeExceptions, which may
not be wanted.
In your case, I'd say, you define a own Exception class that can be used
by programmers to encapsulate their own Exceptions:

<code>
public class MyException extends Exception {
public MyException (String message) { super(message); }
public MyException (String message, Exception cause) {
super(message, cause); }
}
public interface MyInterface {
public void instantiateThisMethod() throws MyException;
}
</code>

In this way, users of you interface know what they must catch (checked
exception MyException).

However, if you define an interface, you should also define what
exceptions are thrown and in which cases a method will throw a checked
or a runtime exception, and of what type that exception will be.
Programmers will have to follow that contract.

Tobi.
 
Reply With Quote
 
 
 
 
chris brat
Guest
Posts: n/a
 
      06-02-2006

> However, if you define an interface, you should also define what
> exceptions are thrown and in which cases a method will throw a checked
> or a runtime exception, and of what type that exception will be.


Are you saying include the runtime exceptions (those extending
java.lang.RuntimeException) in the throws clause too? Not necessary.

 
Reply With Quote
 
seb666fr2@yahoo.fr
Guest
Posts: n/a
 
      06-02-2006

Jama wrote:
> Greetings,
>
> When I build my libraries, I code to interfaces, which is clearly a
> best practice. When programmers then create classes that use my
> interfaces, they complain that the exceptions they want to throw are
> not defined in my signature. For example:
>
> public interface myInterface {
> public void instantiateThisMethod();
> }
>
> is no good. People want interfaces like:
>
> public interface myInterface {
> public void instantiateThisMethod() throws Exception;
> }
>
> This gives the implementing programmer flexibility to throw any
> exception they want.


In this case, the use of RuntimeException (by the implementing
programmer
) is better because you do not have to specify it in the throws clause.


> So now, all my interfaces have "throws Exception" tacked on the end of
> every signature.
>
> Is this a bad idea?


If there is no reason for an abstract method to throw one or more
specific
exception, the use of RuntimeException by the implementing programmer
seems really better.

> What's the proper approach to defining exception handling with interfaces
> from a best practices point of view?


http://www.onjava.com/pub/a/onjava/2...xceptions.html


P.S: sorry for my bad english.

 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      06-02-2006
Jama wrote:

> When I build my libraries, I code to interfaces, which is clearly a
> best practice. When programmers then create classes that use my
> interfaces, they complain that the exceptions they want to throw are
> not defined in my signature.


That's a fundamental problem, which is inherent to the way Java uses interfaces
and checked exceptions. A throws clause is a promise (to the caller of the
method) that it will /NOT/ throw anything except the indicated exceptions (plus
unchecked ones). Not having a throws clause at all is a blanket promise not to
throw (checked) exceptions.

Personally, I have come to doubt the value of this kind of promise (or, more
accurately, come to doubt the value of having the compiler police it so
relentlessly), but that's the way Java works, so that's what we have to live
with.

So the question is, what kind of promise is it appropriate to impose on the
people implementing your interfaces ? It's a tricky design question. On the
one hand (as every user of Java's IO classes knows), having too many throwable
exceptions is a serious pain for the user of the interface. On the other hand
the people implementing the interfaces want as much freedom as possible. It's
your job to balance the conflicting interests.

I would tend to favour the users of the classes, myself. Unless the interface
is one that has an inherent (i.e. visible to any /user/ of the interface)
failure mode, then don't permit it to fail with a checked exception. If it
/does/ have such a failure mode (which is rather common, admittedly), then as
Tobias has already suggested, define your own exception class (which can be
subclassed by interface implementers) and declare that. If the developers
still complain then remind them that exceptions can be chained, and otherwise
ignore them

Also, don't forget the value of unchecked exceptions. There is nothing wrong
with using them -- provided you do it with discretion. They are appropriate
for anything that the user of the interface shouldn't be /forced/ to handle on
every call. That broad class of events includes failure modes which should be
found and eliminated by testing.

Whatever you do, don't declare "throws Exception" !

-- chris




 
Reply With Quote
 
=?ISO-8859-1?Q?Tobias_Schr=F6er?=
Guest
Posts: n/a
 
      06-02-2006
chris brat schrieb:
>>However, if you define an interface, you should also define what
>>exceptions are thrown and in which cases a method will throw a checked
>>or a runtime exception, and of what type that exception will be.

>
>
> Are you saying include the runtime exceptions (those extending
> java.lang.RuntimeException) in the throws clause too? Not necessary.
>

No, that was not what I meant. But you can define what runtime
exceptions should be thrown, e.g. NullPointException, if the arguments
are null or IllegalArgumentException, if the arguments exceed the
allowed value boundaries.
Those things you can define in the javadoc. However, programmers can
throw any other runtime exception they want. But IMO it is a good advice
to follow those definitions (though they could not be forced) and users
know what to expect from a method.

Tobi
 
Reply With Quote
 
Ed Kirwan
Guest
Posts: n/a
 
      06-02-2006
Chris Uppal wrote:

> failure mode, then don't permit it to fail with a checked exception. If it
> /does/ have such a failure mode (which is rather common, admittedly), then as
> Tobias has already suggested, define your own exception class (which can be
> subclassed by interface implementers) and declare that. If the developers
> still complain then remind them that exceptions can be chained, and otherwise
> ignore them
>


> -- chris



Ooo, 'eck, I was about to make a bit of a tit of myself there. Might as
well post it for humility's sake.

I was about to take issue with the ancient and noble Chris and say that
it's no good advising to declare an interface with a method which throws
your own exception class, in the hope that interface implementors can
subclass that exception and throw their own, because, as the interface
method declares a specific exception, then this is the only type that
users of the interface implementations will see: they won't see subclasses.

I thought this was like passing a super-class to a method declared as
receiving a subclass: the method only sees the sublcass, and you have to
instanceof to see what super-class was actually passed in.

But I was wrong.

The code snippet below is prints, "I'm doing something really special."

Which now makes me see exception handling in a new light:
polymorphism-unfriendly. It's just another type of instaceof. Every time
a new interface implementation adds a new exception subclass, then all
users may be impacted (not necessarily, but it's possible).

Another nail in the coffin of exception-handling. (Perhaps that's too
strong a phrase. "Another exception for exception-handling?")




class SpecialException extends Exception {
void doSpecial() {
System.out.println("I'm doing something special");
}
}

class ReallySpecialException extends SpecialException {
void doReallySpecial() {
System.out.println("I'm doing something really special");
}

}

interface Munge {
public void hej() throws SpecialException;
}

public class Test implements Munge {
public static void main(String[] args) {
Munge munge = new Test();
try {
munge.hej();
} catch (ReallySpecialException e) {
e.doReallySpecial();
} catch (SpecialException e) {
e.doSpecial();
}
}

public void hej() throws SpecialException {
throw new ReallySpecialException();
}
}


--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
http://www.EdmundKirwan.com/servlet/...c-page130.html
 
Reply With Quote
 
Dimitri Maziuk
Guest
Posts: n/a
 
      06-02-2006
Chris Uppal sez:
.... If it
> /does/ have such a failure mode (which is rather common, admittedly), then as
> Tobias has already suggested, define your own exception class (which can be
> subclassed by interface implementers) and declare that.


Unfortunately the promise is not just to "not throw anything
else", it's also to throw the declared one. That is, if you
declare a method as throwing MyException, the damn thing will
barf on an implementation that doesn't actually throw anything.

E.g. a data store with 3 different implementations: backed by
file (IOException wrapped inside MyException), DB (SQLException,
ditto), and in-memory store. Apart from an OOM (which you won't
catch/wrap anyway), the last one doesn't throw -- bummer.

Dima
--
I'm going to exit now since you don't want me to replace the printcap. If you
change your mind later, run -- magicfilter config script
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      06-02-2006


Dimitri Maziuk wrote On 06/02/06 12:00,:
> Chris Uppal sez:
> ... If it
>
>>/does/ have such a failure mode (which is rather common, admittedly), then as
>>Tobias has already suggested, define your own exception class (which can be
>>subclassed by interface implementers) and declare that.

>
>
> Unfortunately the promise is not just to "not throw anything
> else", it's also to throw the declared one. That is, if you
> declare a method as throwing MyException, the damn thing will
> barf on an implementation that doesn't actually throw anything.
>
> E.g. a data store with 3 different implementations: backed by
> file (IOException wrapped inside MyException), DB (SQLException,
> ditto), and in-memory store. Apart from an OOM (which you won't
> catch/wrap anyway), the last one doesn't throw -- bummer.


Would you mind clarifying what you mean by "the damn
thing will barf?" When an interface specifies that a
method might throw MyException, neither javac nor the
JVM complains about a method implementation that doesn't
throw it:

public class NotSo implements DataStore {
public void method() {
System.out.println("in method()");
}

public static void main(String[] unused)
throws MyException
{
DataStore store = new NotSo();
store.method();
}
}

class MyException extends Exception {}

interface DataStore {
public void method() throws MyException;
}

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      06-02-2006
Jama wrote:
> Greetings,
>
> When I build my libraries, I code to interfaces, which is clearly a
> best practice. When programmers then create classes that use my
> interfaces, they complain that the exceptions they want to throw are
> not defined in my signature. For example:
>
> public interface myInterface {
> public void instantiateThisMethod();
> }
>
> is no good. People want interfaces like:
>
> public interface myInterface {
> public void instantiateThisMethod() throws Exception;
> }
>
> This gives the implementing programmer flexibility to throw any
> exception they want. So now, all my interfaces have "throws Exception"
> tacked on the end of every signature.
>
> Is this a bad idea? What's the proper approach to defining exception
> handling with interfaces from a best practices point of view?
>
> Thanks,
> J
>


I think the process should start by an effort to determine what
exceptions a user of the interface should be expected to know about and
handle specifically. All of those should be documented with throws
clauses and @throws Javadoc comments.

It doesn't matter that some implementations may not throw all of them.
It does matter that the user of the interface needs to be prepared to
deal with any of them, and needs to know what they mean.

If there is a generic "something broke" condition that the
interface-user cannot do much about, there may be a case for the
implementer extending RuntimeException.

Throwing Exception from everything does not tell the user of the
interface anything about what to prepare for, or how to interpret
exceptions.

Patricia
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
hidden data - best practice, best way, suggestions oldyork90 Javascript 1 09-10-2008 07:46 PM
Question concerning multiline regexps and best practice Oliver Andrich Ruby 8 12-07-2005 07:15 AM
Style and practice question: use of interfaces Richard C. Cobbe Java 28 08-01-2005 12:07 PM
Remember when your piano teacher taught you, "Practice, practice,practice ...?" Wayne Wastier Windows 64bit 3 06-10-2005 08:29 PM
best practice for designing navigation interfaces Simon HTML 14 01-02-2005 09:09 AM



Advertisments