Prev: Controlling content of text field
Next: Build A Home Internet Business For Extra Income Stream
From: Arne Vajhøj on 20 Mar 2010 20:20
On 20-03-2010 20:02, Lew wrote:
> Tom Anderson wrote:
>> If by 'programmer error' you mean an error on the part of the client
>> of the code you're writing, then an AssertionError isn't appropriate.
>> If the problem is a bad argument, then there's good old
>> IllegalArgumentException; if the problem is that your objects haven't
>> been set up right, then it's IllegalStateException. Other than those
>> two, i don't think there are any good general-purpose exceptions in
>> the standard library. Oh, NoSuchElement exception is useful sometimes.
>> And UnsupportedOperationException, but that's not appropriate here. I
>> think Mark is right - you probably need to define a new
>> RuntimeException of your own. Not sure what, though; naming exceptions
>> can be very hard.
>
> One typical approach is to use the project name. For example, for
> (fantasy) website mousierestoration.com one might define a
> 'MousieException' (checked) and a 'MousieRuntimeException' (unchecked),
> defining all four constructors for each.
>
> It's surprising how much mileage just having two custom exceptions can
> give. I've worked on projects where there's a custom exception for every
> durn thing, and it rapidly gets out of hand with little or no added
> benefit.

I would suggest a per project base exception and sub exceptions.

Those that does not care about which it is just catch the base
exception and those that do care can catch sub exceptions.

I consider that the most flexible.

I would hesitate to use the "I don't care about what specific
exception it is now, so probably no one will ever want this"
logic.

I have seen SQLException.

Arne
From: Jean-Baptiste Nizet on 21 Mar 2010 03:35
Stefan Ram a �crit :
> What would be a good (runtime-)exception class from the
> standard library meaning �For reasons I do not understand,
> a called submethod failed, and now I can't do my job.�
>
> For example, method �m� calls �div�, and �div� might throw
> a checked exception named �DivisionByZero�.
>
> The client of �m� does not even know at all that �m� does a
> division, so he should not get this exception, it would make
> no sense to him. Therefore, one would like to repack it into
> a (runttime-)exception that is intended to /make/ sense for
> m's client, but one also believes that this exception will
> never be thrown in the first place (and if it happens:
> indicate a programmer error, not a runtime failure in the
> sense of a harddisk device failure or so). So:
>
> What would be a good class to use instead of
> �WhatToUseHereException� below?
>
> public void m()
> { ...
>
> if( y != 0 )
> { try
> { q = div( x, y ); }
> catch( final DivisionByZero divisionByZero )
> { throw new WhatToUseHereException( divisionByZero ); }}
>
> ... }
>
> I believe, a runtime exception is more appropriate here than
> a checked exception, but do not know which specific runtime
> exception is best.
>

In previous projects, I simply used RuntimeException for these cases
(wrapping the original one). In my last toy project, I decided to go for
a more specific custom runtime exception named
ShouldNeverHappenException (still wrapping the original one).

JB.
From: Roedy Green on 21 Mar 2010 09:13
On 20 Mar 2010 20:33:41 GMT, ram(a)zedat.fu-berlin.de (Stefan Ram)
wrote, quoted or indirectly quoted someone who said :

>{ throw new WhatToUseHereException( divisionByZero ); }}

throw new IllegalArgumentException("km cannot be 0");
--
Roedy Green Canadian Mind Products
http://mindprod.com

Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, �How would I develop if it were my money?� I�m amazed how many theoretical arguments evaporate when faced with this question.
~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming.
First  |  Prev  | 
Pages: 1 2
Prev: Controlling content of text field
Next: Build A Home Internet Business For Extra Income Stream