Hi, In general I like the idea. Some input for the exception handling topic: - there are tons of places where Throwable, RuntimeException and other generic exceptions are caught. It should be clear which exception is caught where. Throwable probalby should not be cought :) - there other tons of cases where if any error caught, null is returned rather than an expected result, this later results in an NPE. (See "NullPointerException on agent while remounting primary storage" recently on users list) these cases need to be handled as well to correct the error flows.
On Mon, Oct 14, 2013 at 7:29 PM, Darren Shepherd < darren.s.sheph...@gmail.com> wrote: > I'm going through and updating all the code to use what I had proposed > with Transaction management. This has uncovered more fun issues > around exception handling. Well, not an issue per say, but just > pointed out the ridiculous amount of checked exceptions in method > signatures. I generally follow the "avoid checked exceptions at all > costs" camp. The majority of the time the caller is forced to catch > some checked exception, but then doesn't know what to do with it, so > the exception handling is not correct. Pretty much the only time I > typically use checked exceptions is with IOException and its > subclasses. Basically when you are calling some method, if that > method does I/O, you should know as the caller because bad stuff > happens with I/O. > > I'd like to transition ACS to more unchecked exceptions eventually. > At the moment, I've found two exceptions that I'd really like to > change to be unchecked. Those are InsufficientCapacityException and > ConcurrentOperationException. Would anybody have an objection to me > changing those exceptions to be unchecked? I might find more as > things go along, but those two are causing a bunch of problems for me. > The change will just be moving from "extends CloudException" to > "extend CloudRuntimeException." > > Darren > -- EOF
