You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Glen Mazza <gr...@yahoo.com> on 2005/04/07 18:07:01 UTC

Re: cvs commit: xml-fop/src/java/org....

Jeremias,

I do not fully understand the business logic for
tables--so what I am saying here may not be relevant.

But if cell should *never* be null (i.e., the caller
of this method is very sloppily written), please let
the methods NPE, raise IndexOutOfBoundsError,
InvalidStateException, etc., so we can immediately be
informed of the caller's incompetence at the point of
error and work on that right away.

Make sure we don't quietly return null so that the
problem will resurface several classes further
downstream where it presumably would be much harder to
track.  If we have to put a temporary band-aid in,
best to put it with caller (i.e., have it not call the
method if "cell" is null), not the callee.

Thanks,
Glen

--- jeremias@apache.org wrote:
>   +    public BorderInfo
> getOriginalBorderInfoForCell(int side) {
>   +        if (cell != null) {
>   +            return
>
cell.getCommonBorderPaddingBackground().getBorderInfo(side);
>   +        } else {
>   +            return null;
>   +        }
>   +    }



Should empty table-cells throw NPE? (was Re: cvs commit: xml-fop/src/java/org....)

Posted by The Web Maestro <th...@gmail.com>.
As I stated in a previous post, I'm not convinced that throwing an NPE 
is the best choice. At the very least (IMO) this should be configurable 
(and again IMO, it should default to WARN instead of ERROR).

Web Maestro Clay

On Apr 7, 2005, at 9:07 AM, Glen Mazza wrote:
> Jeremias,
>
> I do not fully understand the business logic for
> tables--so what I am saying here may not be relevant.
>
> But if cell should *never* be null (i.e., the caller
> of this method is very sloppily written), please let
> the methods NPE, raise IndexOutOfBoundsError,
> InvalidStateException, etc., so we can immediately be
> informed of the caller's incompetence at the point of
> error and work on that right away.
>
> Make sure we don't quietly return null so that the
> problem will resurface several classes further
> downstream where it presumably would be much harder to
> track.  If we have to put a temporary band-aid in,
> best to put it with caller (i.e., have it not call the
> method if "cell" is null), not the callee.
>
> Thanks,
> Glen
>
> --- jeremias@apache.org wrote:
>>   +    public BorderInfo
>> getOriginalBorderInfoForCell(int side) {
>>   +        if (cell != null) {
>>   +            return
>>
> cell.getCommonBorderPaddingBackground().getBorderInfo(side);
>>   +        } else {
>>   +            return null;
>>   +        }
>>   +    }
>
>
>

Web Maestro Clay
-- 
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


Re: cvs commit: xml-fop/src/java/org....

Posted by Jeremias Maerki <de...@greenmail.ch>.
No, this is by design. A GridUnit instance for an empty cell
(this.cell=null) must return null for this method. Just right-click on
the method name in Eclipse and choose References/Project. This will
bring you to the CollapsingBorderModelEyeCatching class which is
responsible for border resolution. The set of borders for the cell level
must be null for an empty cell. In this case only row (optional), column,
column group (NYI) and table levels apply here for border resolution.
Sure, it could be implemented differently but it was convenient here.
I'll add javadocs accordingly explaining all this as soon as I'm
convinced that the design holds up.

On 07.04.2005 18:07:01 Glen Mazza wrote:
> Jeremias,
> 
> I do not fully understand the business logic for
> tables--so what I am saying here may not be relevant.
> 
> But if cell should *never* be null (i.e., the caller
> of this method is very sloppily written), please let
> the methods NPE, raise IndexOutOfBoundsError,
> InvalidStateException, etc., so we can immediately be
> informed of the caller's incompetence at the point of
> error and work on that right away.
> 
> Make sure we don't quietly return null so that the
> problem will resurface several classes further
> downstream where it presumably would be much harder to
> track.  If we have to put a temporary band-aid in,
> best to put it with caller (i.e., have it not call the
> method if "cell" is null), not the callee.
> 
> Thanks,
> Glen
> 
> --- jeremias@apache.org wrote:
> >   +    public BorderInfo
> > getOriginalBorderInfoForCell(int side) {
> >   +        if (cell != null) {
> >   +            return
> >
> cell.getCommonBorderPaddingBackground().getBorderInfo(side);
> >   +        } else {
> >   +            return null;
> >   +        }
> >   +    }
> 



Jeremias Maerki