On 10/14/13 10:29 AM, "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. +1, I'm in this group too. Although using checked exception to represent business logic in non-normal flow, it is quite intrusive to all the callers above it. I prefer to handle business flow with regular error/result objects, and follow a well-documented convention to handle run-time exception (which you have to handle anyways). IMO, this practice can help make code more cleaner, although some people may argue that exception handling may not be that explicit. -Kelven > 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
