Re: Assert vs Exceptions [was: svn commit: r731248 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/foschema/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/autodetect/ src/java/org/apache/fop/fonts/truetype/ src/java/org/apache/fop/render/ sr...]

[Vincent Hennebert <vh...@gmail.com>]

Jeremias Maerki wrote:
> On 07.01.2009 12:36:34 Vincent Hennebert wrote:
>> Jeremias Maerki wrote:
>>> Hi Vincent
>>>
>>> On 07.01.2009 11:47:16 Vincent Hennebert wrote:
>>>> Hi Jeremias,
>>>>
>>>>> Author: jeremias
>>>>> Date: Sun Jan  4 04:59:29 2009
>>>>> New Revision: 731248
>>>> <snip/>
>>>>> +    /**
>>>>> +     * Sets the requested encoding mode for this font.
>>>>> +     * @param mode the new encoding mode
>>>>> +     */
>>>>> +    public void setEncodingMode(EncodingMode mode) {
>>>>> +        if (mode == null) {
>>>>> +            throw new NullPointerException("mode must not be null");
>>>>> +        }
>>>>> +        this.encodingMode = mode;
>>>>> +    }
>>>> <snip/>
>>>>>          if (type1) {
>>>>> +            if (encodingMode == EncodingMode.CID) {
>>>>> +                throw new IllegalArgumentException(
>>>>> +                        "CID encoding mode not supported for Type 1 fonts");
>>>>> +            }
>>>> I’d rather use assert statements instead. Anything wrong with that?
>>> Nothing, it's a matter of taste. For these cases here, I prefer
>>> exceptions.
>> No big deal of course, but let me just explain my view of assert vs
>> exception:
>> - if the error is due to an illegal use of the library, I use an assert
>>    and expect the developer to test his program with assertions enabled,
>>    debug it and then put it in production with assertions disabled. That
>>    saves some checking overhead.
>> - if the error is due to some external cause (missing resource, invalid
>>    URL, etc.) then an exception is to be used.
>>
>> I don’t know the context, but in this case it seemed to correspond to
>> the first situation, hence my question.
>>
>> Vincent
> 
> I understand your reasoning, but looking around on the net, I find that
> best practice seems to be to use explicit checks for parameters of
> public methods and asserts only for private methods and code consistency
> checks. That basically matches my understanding of the facility and how
> I try to use it.
> 
> http://docs.sun.com/app/docs/doc/806-7930/6jgp65iks?a=view#assert-13
> http://www.jfasttrack.com/whitePapers/assertions.html
> http://goliath.ecnext.com/coms2/gi_0199-1331586/Using-assertions-in-Java-building.html

Thanks for the links. Indeed that makes sense to use exceptions in
public methods; but then they need to appear in the javadoc I think,
even if they are unchecked exceptions.

I’ll apply that convention from now on. But to be honest, I’m not too
keen on constantly checking for e.g. null arguments. I guess it’s all
a matter of how ‘obvious’ this is that the argument must not be null...

Vincent