What exception to use for incorrect file format?

Question

I parse a file and find out that it contains unsupported elemnet.

Answer 1

You are applying a general case to specificinstance
without knowing any of the details.Indeed I am. However, generally speaking, a method
that throws Exception is less-than-optimal design in
an API. I will try to illustrate my point.
Throwing an Exception does not provide any clues to
the user of your API about what might go wrong in the
method call, while throwing an
UnsupportedElementException certainly does. An
UnsupportedElementException is much more informative
to the user, while a plain Exception is not. A custom
exception in this case is implicitly clear, even
without consulting the Javadocs.Which is all true if I am writing a library. But most people do not write libraries, they write applications. In applications either exceptions are part of the process flow (explicitly caught) or they are not. The vast majority are not part of the process flow.
>
The only time you should create a custom exceptionis
when you believe it will be possible for someone todo
something intelligent with it.Are you always able to tell in advance whether the
user of you API can do something intelligent with an
exception? Can you make the supposition that the user
can never do anything meaningful with the exceptions
you throw? I am not convinced that you can, at least
not in most of the cases.One should never ever design or code solely based on the "hope" that sometime in the future someone "might" need it. Doing that leads to code bloat, code that is hard to understand and worst of all code that is never tested.
So unless there is a known need a special exception should not be created.
>
If I am creating an application that automatically
moves data via a socket and that must move thedata,
then I don't care why the socket failed to connect.I
am simply going to keep retrying until it does
connect. In this case an Exception is perfectly
acceptable.
On the other hand the same application might wantto
resolve the DNS name first and simply give up if it
can't resolve it. But still continue if the
connection timed out. In this case at least one
custom Exception is needed to differentiate between
the two failure paths.Agreed. And to make the API nice and neat, write two
meaningful custom exceptions to differentiate the
failures. :)Nope. Again that is fine for a library. It is not needed for an application. An application has a purpose which is defined by the requirements. Adding stuff when there is neither a current requirement or when there is no expected future requirement is a bad idea.
I have yet to meet a developer who can accurately predict the future. I have however met many who thought there code could be generalized for many possible imaginary cases that they conceived in their mind.
And all that extra code is never tested by QA (because there are no requirements) and causes maintenance problems down the road because it is not part of the documented infrastructure.
also it forces the user of
you API to catch all Exceptions.That is obviously non-sensical. Regardless of the
checked exception being used, you still have tocatch
it.I did not mean that you force the user of your API to
write a try-catch -block, I meant that you force the
user of your API to catch each and every exception
that inherits from java.lang.Exception. Even
RuntimeExceptions; and that can be a problem.
I have no idea what you are trying to express there.
A checked exception must be caught regardless of what type of checked exception it is. The user might break it out but only if the user expects to do something with a specific type of exception.