panic: runtime error: index out of range [0] with length 0

[tumbleweedd]

Subject of the issue

I get the following panic when using the library github.com/xuri/excelize/v2: panic: runtime error: index out of range [0] with length 0

Your environment

• usee golang 1.19
• use excelize/v2@v2.7.0

Steps to reproduce

the client had a panic. for what reason is unclear
the code is approximately as follows

package main

import (
  "fmt"
  "github.com/xuri/excelize/v2"
  "log"
  "os"
)

type axisCounter struct {
  Row    int64
  Column []rune
}

func newAxisCounter() *axisCounter {
  axis := new(axisCounter)
  axis.Row = 1
  axis.Column = append(axis.Column, 'A')
  return axis
}

func (axis *axisCounter) getAxis() string {
  return fmt.Sprintf("%s%d", string(axis.Column), axis.Row)
}

func main() {
  file, err := os.Open("panic_import_ob (1).xlsx")
  if err != nil {
    log.Fatal(err)
  }
  defer file.Close()

  fileXlsx, err := excelize.OpenReader(file)
  if err != nil {
    log.Fatal(err)
  }
  defer fileXlsx.Close()

  sheet := fileXlsx.GetSheetName(0)

  rows, err := fileXlsx.Rows(sheet)
  if err != nil {
    log.Fatal(err)
  }
  defer rows.Close()

  var (
    axis = newAxisCounter()
  )

  for rows.Next() {
    row, err := rows.Columns()
    if err != nil {
      log.Fatal(err)
    }

    for _, cell := range row {
      cellType, err := fileXlsx.GetCellType(sheet, axis.getAxis())
      if err != nil {
        continue
      }

      if cellType == excelize.CellTypeDate {
        cell, err = changeDateFormat(fileXlsx, sheet, axis.getAxis())
        if err != nil {
          log.Fatal(err)
        }
      }
      fmt.Println(cell)
    }
  }

}

var xlsxNumberFormat = "yyyy-mm-dd"

func changeDateFormat(fileXlsx *excelize.File, sheet, axis string) (cell string, err error) {
  style, err := fileXlsx.NewStyle(&excelize.Style{CustomNumFmt: &xlsxNumberFormat})
  if err != nil {
    log.Fatal(err)

  }
  err = fileXlsx.SetCellStyle(sheet, axis, axis, style)
  if err != nil {
    log.Fatal(err)

  }
  cell, err = fileXlsx.GetCellValue(sheet, axis)
  if err != nil {
    log.Fatal(err)

  }

  return cell, nil
}

Actual behaviour

panic occurs when the getCellType method is called in the cellType, err := fileXlsx.GetCellType(sheet, axis.getAxis())

Expected behaviour

there should obviously be no panic. it is unclear for what reason it appears, since there is no way to view the problematic client file. maybe it's the version? has anyone encountered such behavior? unfortunately, there is no way to check whether it is the version or not, since (as I said) there is no way to repeat the panic due to lack of access to the client file

Log

panic: runtime error: index out of range [0] with length 0

goroutine 2773676 [running]:
github.com/xuri/excelize/v2.checkSheet(0xc00bcff880)
  /root/go/pkg/mod/github.com/xuri/excelize/v2@v2.7.0/excelize.go:311 +0x490
github.com/xuri/excelize/v2.(*File).workSheetReader(0xc0097fcd00, {0xc002eaec48, 0x8})
  /root/go/pkg/mod/github.com/xuri/excelize/v2@v2.7.0/excelize.go:268 +0x714
github.com/xuri/excelize/v2.(*File).getCellStringFunc(0xc009bbe000?, {0xc002eaec48?, 0xc00983df80?}, {0xc002eaf8ac, 0x2}, 0x31aaa18)
  /root/go/pkg/mod/github.com/xuri/excelize/v2@v2.7.0/cell.go:1272 +0x79
github.com/xuri/excelize/v2.(*File).GetCellType(0x30532d0?, {0xc002eaec48?, 0xc00983df80?}, {0xc002eaf8ac?, 0x2?})
  /root/go/pkg/mod/github.com/xuri/excelize/v2@v2.7.0/cell.go:87 +0x2a

here is the file that was provided to me, but it does not cause panic, but perhaps reflects the structure of the client's file: panic_import_ob (1).xlsx

based on the function in which the panic occurred, I can't understand why this happened

[xuri]

Thanks for your issue. I have tested your code with the attachment in v2.7.0, and it works well. We need more details info or a reproducation demo for this. May be the pull request #1692 resolve the same problems with this.

[xuri]

I have merged the pull request #1692 to resolve this issue. This patch will be released in the next version.

[xuri]

According to the benchmark report of v2.8.1, the fix for this (commit: 6220a79) slows down the get rows about 3 times, and memory using about 17 times. We need to fixed the performance impact later.