> On 23 May 2015, at 23:15, Andreas Delmelle <andreas.delme...@telenet.be> 
> wrote:
<snip />
> FYI  - High and medium priority warnings addressed in r1681384, and absent an 
> answer to my question, assumed the lazy approach there, for now.
> Will try to have a look at the low priority ones tomorrow.

... and low priority warnings now addressed in r1681435.

Going through those, the number of implicit assertions made at various places 
in the codebase is quite amazing.

In some cases, making those explicit looks a bit silly, but it actually makes 
perfect sense.

Example from the o.a.f.render.afp package:

/** {@inheritDoc} */
protected AFPDataObjectInfo createDataObjectInfo() {
    return new AFPGraphicsObjectInfo();

/** {@inheritDoc} */
public void handleImage(RenderingContext context, Image image, Rectangle pos)
        throws IOException {
    AFPRenderingContext afpContext = (AFPRenderingContext)context;

    AFPDataObjectInfo info = createDataObjectInfo();
    assert (info instanceof AFPGraphicsObjectInfo);
    AFPGraphicsObjectInfo graphicsObjectInfo = (AFPGraphicsObjectInfo) info;

For us, humans, it looks evident that casting the object returned by 
createDataObjectInfo() to an AFPGraphicsObjectInfo is legitimate. 
However, strictly speaking, one cannot exclude the possibility that someone 
creates a subclass and  overrides createDataObjectInfo(), but not 
handleImage(), in which case the code would fail at runtime with an ugly 

Perhaps it is also possible and cleaner to force the return type to an 
AFPGraphicsObjectInfo, which is a subclass of AFPDataObjectInfo. I may look 
into that later. At least now, the assertion is clearly visible in the code.



Reply via email to