Exception or Return
Is it better practice to be throwing exceptions, or a return value to signify something wasn't done right, I am very used to C where everything is a return.
[164 byte] By [amattasa] at [2007-11-27 11:34:12] 
An exception is usually better, though the time overheads are slightly higher. Especially, of course, if the method has to return data of some sort when it does work.
malcolmmca at 2007-7-29 16:55:56 >
An exception can provide much more detail describing what went wrong than a 'return value' can.
For instance, let's say your method returns a simple numeric value. What numeric value would you propose to mean "something went wrong" (an exception)? -1? 42? And can you glean from that numeric value what it was that went wrong?
warnerjaa at 2007-7-29 16:55:56 >
> An exception is usually better, though the time
> overheads are slightly higher. Especially, of course,
> if the method has to return data of some sort when it
> does work.
This is the wrong moment to worry about micro-efficiencies!
BigDaddyLoveHandlesa at 2007-7-29 16:55:56 >
How would I go about creating a custom exception, I googeled it and got a lot of irrelevant data back.
amattasa at 2007-7-29 16:55:56 >
@Op. Many books say that you should use exception for unexpected problems/errors and return values (if you can) for expected problems/errors.
E.g a find method shouldn't throw an exception if it can't find any data, but it should throw an exception if it can't execute the query.
Kaj
kajbja at 2007-7-29 16:55:56 >
> How would I go about creating a custom exception, I
> googeled it and got a lot of irrelevant data back.
The same way you define any class. It just has to be directly or indirectly
derived from Throwable.
BigDaddyLoveHandlesa at 2007-7-29 16:55:56 >
I think best practise is to use exceptions because that has several advantages.
Exceptions are a language feature that serve their purpose very well.
Some points to think of:
- Using exceptions makes the code more readable, because it separates main code from the error code.
- Using exceptions makes the code more readable, because you're encouraged to name or order your exceptions, instead of using error codes.
- Using exceptions makes sure that all exceptions are caught exactly once, because otherwise the compiler will complain. This way you cannot get bugs because of forgetting the error check.
- Using exceptions comes in very handy for writing the cleanup code (for closing streams etc.), where without the exception mechanism one would have to use labels or functions.
tom_jansena at 2007-7-29 16:55:56 >
> Is there anything special I have to define in it?
No. It is just another class. But you seem to have something in mind?
BigDaddyLoveHandlesa at 2007-7-29 16:55:56 >
> Is there anything special I have to define in it?
No; except you know you want that.
So, if you want your exception class to carry special error details, then define member for those.
The Exception class already has a member for the error descripion.
If you are extending this class, you can pass a description to the superconstructor.
But only if you have use for that. Otherwise you don't have to define anything special in it.
tom_jansena at 2007-7-29 16:55:56 >
Normally declare it as extends Exception, that makes it a "checked" exception so that you have to declare it in throws clauses.
Typically you'll want to pass some message text to the superclass using a super constructor (this text is what getMessage() returns).
A common technique is "wrapped" excetions, when an exception caught inside a method is wrapped in a used defined exception, allowing a common method signature at a higher level. On stack traces this gives you a "Caused By" line, followed by details of the wrapped exception.
Something like:
public class FooException extends Exception {
public FooException() {
super("Foo exception");
}
public FooException(String msg) {
super(msg);
}
public void FooException(String msg, Throwable t) {
super(msg);
initCause(t);
}
}
malcolmmca at 2007-7-29 16:55:56 >
>public void FooException(String msg, Throwable t) {
>super(msg);
>initCause(t);
>}
Or just
public void FooException(String msg, Throwable t) {
super(msg, t);
}
(Since 1.4)
BigDaddyLoveHandlesa at 2007-7-29 16:55:56 >
Java Essentials New Topic
Java Essentials Hot Topic
Java Essentials
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding