J
James L
How do you all feel about the commonly-seen technique of exception
wrapping? It can keep interfaces clean - but then you end up breaking
compile-time exception handling checking, as pointed out here:
http://weblogs.java.net/blog/bakksjo/archive/2005/09/java_exception.html
(and you risk never dealing with exceptions that are added to the code
later on...)
Also, suppose I have a class that contains ten methods, each of which do
something similar (e.g. comms) which can throw the same five exceptions
each time. Is there a handy pattern for refactoring those five catch
statements into one place, if such a thing were desirable?[1] (This is
maybe drifting into the area of aspect-oriented programming...)
One naive way might be to have each of the ten methods call a single
method with parameters, which contains a switch which calls the correct
ultimate target method - then you just have one try...catch wrapping
that switch statement. This is pretty ugly though.
[1] I realise that such a thing might very rarely be actually desirable!
thanks,
J
wrapping? It can keep interfaces clean - but then you end up breaking
compile-time exception handling checking, as pointed out here:
http://weblogs.java.net/blog/bakksjo/archive/2005/09/java_exception.html
(and you risk never dealing with exceptions that are added to the code
later on...)
Also, suppose I have a class that contains ten methods, each of which do
something similar (e.g. comms) which can throw the same five exceptions
each time. Is there a handy pattern for refactoring those five catch
statements into one place, if such a thing were desirable?[1] (This is
maybe drifting into the area of aspect-oriented programming...)
One naive way might be to have each of the ten methods call a single
method with parameters, which contains a switch which calls the correct
ultimate target method - then you just have one try...catch wrapping
that switch statement. This is pretty ugly though.
[1] I realise that such a thing might very rarely be actually desirable!
thanks,
J