Throw an IOException or chain/wrap it

[Salman Ahmed]

I am developing a class library that provides access to a Server based application over TCP/IP sockets. All functional operations possible through my class library essential invoke a request-response cycle over the underlying socket connection to my server. So, for almost all of these operations an IOException can be generated while sending the request and/or reading the response over the wire.

My question is: is it advisable to just throw an IOException for all my public operations or should I define a custom MyAppException class and chain the IOException to it and have my public operations just throw the MyAppException custom exception class?

Lack of experience with real-world Java programming and lack of knowledge of Java best practices is what's really driving this question!

Thanks for any advice or suggestions.
Regards,

[Peter Chase]

My view is that it depends whether IOException will cover all possible future requirements.

As an example, say you define a method getData() that gets some data from somewhere. Currently, you implement it to read a file, so the internal operations can throw IOException. Should you declare getData() to throw IOException or your own exception?

Say you later decide to use a database-based implementation. Then the internal operations will typically throw SQLException. Your declaration of getData() throwing IOException has become inappropriate.

If you think that sort of thing may happen in your application, then defining your own wrapper exception avoids it.

But, if you think that's unlikely, then defining your own wrapper is just bloat.

As with many things, you have to make an educate guess about the future.