I have a try/catch block which looks like this :

try {
} catch(IllegalArgumentException e) {
    System.out.println("ligne n°" + counter + " : " + e.getMessage());

My function convertLineToGeom might throw different exceptions that I made myself, all of them extending IllegalArgumentException.

Question is, which is best practice (both codes work) between :

public static <E extends IllegalArgumentException> IGeomD2 convertLineToGeom(String ln) throws E {


public static IGeomD2 convertLineToGeom(String ln) throws IllegalArgumentException {

I feel like the first one states well that the function doesn't throw IllegalArgumentException but some of its children.... So which is the best typo ?

  • Generally, I'd recommend not to invest too much effort into designing exceptions. Why? If you expect the caller to react on information you want to put into your Exception, consider extending your return type to cover that case instead of throwing exceptions. And if you don't expect the caller to react specifically, then ANY exception will do (and any exception contents will be meant for logging purposes only). – Ralf Kleberhoff Oct 23 '17 at 11:41
  • By the way, your try/catch code snippet continues after swallowing and printing the exception. From my experience, 99% of all algorithms can't continue successfully if some step failed. So, routinely I either don't catch exceptions at all, or re-throw them (or a wrapped version of them) after doing whatever was necessary in the catch block. – Ralf Kleberhoff Oct 23 '17 at 11:45
  • @RalfKleberhoff in that case it's not a problem, the algorithm is reading a file, and when it can't convert a line into object it just goes to the next line. There I just wanted to tell the user that this line will not be used for different reasons depending on the exception. – Paul Lemarchand Oct 23 '17 at 11:46
  • But yes, any exception will do there, as the answer stated. So the second typo is good enough. – Paul Lemarchand Oct 23 '17 at 11:47
  • What I meant was to not even create IllegalArgumentException subclasses (unless useful for logging, with the aim of communicating state information) and use the plain IllegalArgumentException. Ask yourself: how deep do I want to model different failure situations if no-one will care about their differences? – Ralf Kleberhoff Oct 23 '17 at 11:56

There is no point in forcing your callers to use a complicated type expression for this purpose. They expect to get an IllegalArgumentException as usual, and the fact that you are delivering helpful subclasses of this standard type shouldn't impose more burdens on the caller, since the normal catch(IllegalArgumentException) still works (that what's substitutability is all about, after all).

The only reason to expose the fact that you're using subclasses would be when you use more informative fields than just the standard message in your custom exceptions. But even then you should explicitly declare throws PaulException rather than an expression with a type variable, even if you have multiple subclasses of PaulException.

The rule of thumb is: declare return types (and yes, throwing exceptions is a kind of returning) only in enough detail that the caller can use the fields they need.

  • Thank your for your answer ! So there is no benifits whatsoever to using the firt typo ? – Paul Lemarchand Oct 23 '17 at 11:24
  • 2
    Only if you want to supply different concrete types in different situations. For instance, a Collection<T extends Number> might be extended both to a concrete Collection<Real> and to a Collection<Complex>. But I can't think of an analogous requirement for exception types. – Kilian Foth Oct 23 '17 at 11:56
As yourself not which is the best to *throw* ... 
As yourself which is the most useful to *catch*! 

Why do we have multiple Types of Exception? So that the catching code can handle them differently.

If all you want to do is put a message on the screen and kill the program stone dead, then all you ever need is Exception itself.

If you want some code to be able to catch a SomethingNastyHappenedButYouCanDoSomethingAboutItException, use the value(s) that are passed in that Exception to figure how to and then do something [useful] about it and then allow the program to carry on - all without the user knowing anything about it - then you need more complex Types of Exception.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.