[DISCUSS] Checked Exceptions

[Darren Shepherd <da...@gmail.com>]

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

Re: [DISCUSS] Checked Exceptions

[Laszlo Hornyak <la...@gmail.com>]

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.shepherd@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

Re: [DISCUSS] Checked Exceptions

[Kelven Yang <ke...@citrix.com>]

On 10/14/13 10:29 AM, "Darren Shepherd" <da...@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