Docx writer crashes on invalid tables

[tarleb]

The docx writer crashes with error pandoc: Error in array index when processing an inconsistent/invalid table that has fewer cells in a row than expected. This only shows when processing JSON or native input, as in those cases the tables are not necessarily normalized:

[ Table
    ( "" , [] , [] )
    (Caption Nothing [])
    [ ( AlignLeft , ColWidth 0.5 )
    , ( AlignLeft , ColWidth 0.5 )
    ]
    (TableHead ( "" , [] , [] ) [])
    [ TableBody
        ( "" , [] , [] )
        (RowHeadColumns 1)
        []
        [ Row
            ( "" , [] , [] )
            [ Cell
                ( "" , [] , [] )
                AlignLeft
                (RowSpan 1)
                (ColSpan 1)
                [ Plain [ Str "single" ] ]
            ]
        , Row
            ( "" , [] , [] )
            [ Cell
                ( "" , [] , [] )
                AlignLeft
                (RowSpan 1)
                (ColSpan 1)
                [ Plain [ Str "one" ] ]
            , Cell
                ( "" , [] , [] )
                AlignLeft
                (RowSpan 1)
                (ColSpan 1)
                [ Plain [ Str "two" ] ]
            ]
        ]
    ]
    (TableFoot ( "footer" , [] , [] ) [])
]

The second row in the table above is necessary to trigger the error.

[jgm]

I'd guess it's T.P.Writers.Docx.Table l. 195, with the ! indexing an array.
We shouldn't assume that the array will have something at that index.

[tustin2121]

This is still an issue I'm having in the latest version (3.6.1). I was writing a custom table output filter and got the col_span and row_span backwards in the output (so it was trying to span 5 rows instead of 5 columns), and the docx writer just crashed with this error message and nothing more useful.

I managed to finally fix my filter thanks to this bug writeup, but I'm still annoyed that pandoc didn't provide any useful feedback on what was wrong with the output. At least prior to getting this error, I got errors about invalid row formats in $.block[18][0][0] and the like, which while cryptic at least was some feedback that I was able to use to look through the json output.

[jgm]

Re-opening because @tarleb's fix didn't address the Docx writer's assumption noted above. I think we should change something there, too; certainly we shouldn't be exiting with an array index error.