Why don't functions need to specify "throws ClassCastException"? 2

[cpjust]

When you write code in Java, Eclipse complains if your function doesn't have a "throws blah" declaration for each of the exceptions that it can throw, but for some reason it doesn't require you to add "throws ClassCastException" if you're casting some stuff...

Why doesn't it require that?

 

[TonHu]

It's not going to know beforehand if the cast will be invalid at runtime. OTOH, if you declare "throw SomeException", it's quite explicit that at some point you are going to throw that, so you'd better declare "throws SomeException" with the method definition, and the caller can be prepared by catching that exception. As you define it going to be possibly thrown, you either rethrow it from the caller by re-issuing the "throws SomeException" definition on that method, or catch it and act upon it.

That's not hard, just by definition.

HTH
TonHu

 

[cpjust]

But that's true for any exception.
You might have a crappy hard disk and get an kinds of IO Errors or you might never get an exception when reading a file. The fact is, it's possible for certain exceptions to be thrown. So why are only some required to be declared and not others?

 

[preachie]

The ClassCastException is a subclass of the RuntimeException

Take a look at

http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

I think the most important part to answer your question is:

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

Maybe that helps

 

[TonHu]

Biggest difference is that you don't explicitly throw the ClassCastException from your code, but it is, as preachie said, a runtime issue, and so rather unexpected, as in: Should not normally occur.
If you where to declare an exception, to be able to handle that, then every Java source would have to list all exceptions defined, just 'to be prepared', that's not going to happen ;-)

HTH
TonHu

 

[cpjust]

Hmm... So RuntimeExceptions are unchecked? I never knew that; and all this time I've been explicitly throwing RuntimeExceptions when I couldn't find a specific one that fits & I was too lazy (busy) to write my own exception class...

It still seems like a double-standard though... Lets make these exceptions unchecked because otherwise we'd have to do too much typing...
Maybe I'm just too used to C++.

 

[Diancecht]

Other people think that checked exceptions are a mistake.

I like this article

Cheers,
Dian

 

[cpjust]

Exception Specifications in C++ were a mistake too:

http://www.gotw.ca/publications/mill22.htm

Either make all exceptions checked or all unchecked. I think the problem comes when you start mixing them.

 

[MoreFeo]

Well, as far as I know in java you never need to check or declare a RuntimeException, and any of it's subclasses.

Runtime exceptions are usually (not ever) due to wrong programming (a null pointer, array index out of bounds, a wrong class cast, dividing by zero, etc...). These errors should be corrected in the code (checking for nulls, checking for zero before dividing, etc...) instead of being thrown.

 

[Diancecht]

Mayeb I'm too used to Java, but I find them useful. For example, if you have a SQL statement, I think you must capture SQL exceptions, but there's no point on catching an OutOfMemory error.

Also, you can define your own exception and force callers to catch it. This way you offer a contract that everyone who calls you needs to agree.

Cheers,
Dian

 

[cpjust]

Well, if they must have checked & unchecked exceptions, it probably would have been less confusing if the exception hierarchy branched into 2 paths like this:

Exception <-- CheckedException
Exception <-- UncheckedException

Then every other exception must derive from CheckedException or UncheckedException and never directly from Exception.

 

[MoreFeo]

OutOfMemoryError is a subclass of java.lang.Error, it's not a RuntimeException.
These errors doesn't need to be caught or declared neither, and they may seem similar to runtime exceptions, but there are some differences.

You cannot check in your code for a condition that could throw these errors (as dividing by zero, or accesing a null object), and the main reasons you don't need to catch them is that you can't recover from this errors, and you don't know where you can get one.

 

[MoreFeo]

As an abstract, we've got:

- Throwable
   - Error (unchecked)
   - Exception
      - RuntimeException (unchecked)
      - All the rest (checked)

If it's an error or a runtime <-- unchecked
If it's any other exception <-- checked

 

[cpjust]

You can easily check whether you're about to divide by zero or access a null object.

int num = 1;
int div = 0;
...
if ( div != 0 )
   result = num / div;
----------------------------
if ( obj != null )
   obj.someFunc();

What you can do about them depends on what your function is doing, but in most cases the only sane thing to do is throw an exception and let someone further up deal with it.

 

[Diancecht]

You can catch Throwables, and there may be a reason to do that, for example write an error message on a queue before exiting the JVM ...

Cheers,
Dian

 

[MoreFeo]

This is what I meant, in the case of runtime exceptions there are some conditions you can check in your code (dividing by zero or accesing a null object throw RuntimeExceptions).

But in the case of errors, there aren't such conditions you can check (no way to check for what can cause an OutOfMemoryError).

Maybe I didn't express myself clearly, but what I wanted was to compare RuntimeExceptions (the ones you can check and correct in your code) with Errors, that you cannot check or correct.

 

[Diancecht]

I don't agree you can't catch or correct an error.

Imagine an AWTError. You can actch it and relaunch the graphical interface under Swing or SWT. Or a ThreadDeath error: you can catch it to free resources and the throw it again.

Cheers,
Dian

 

[MoreFeo]

What I mean it's when you get an Error it's not due to a lack of checking in the code.

When you get a NullPointerException or IndexOutOfBounds you can edit the code to prevent these RuntimeExceptions (checking for null objects, checking for the size of the array, etc...).
This is what I meant when I talked about checking and correcting, correct them while programming, not while running the app.

With Errors there is little you can edit in the code to prevent the errors to occur. You can catch them, but not prevent them.

 

[Diancecht]

Again, I don't agree.

An OutOfMemoryError can be avoided with a correct programation. A linkage error may be corrected by changing the classes you're using.

Cheers,
Dian