【v17】该问题是否可在spread内部进行try catch，确保API调用时不会导致页面卡死

https://gcdn.grapecity.com.cn/showtopic-224479-1-1.html

该问题是否可在spread内部进行try catch，确保API调用时不会导致页面卡死？目前的效果是页面卡死，控制台报错，js执行resumePaint后，格式刷无法使用了
作为框架使用者，调用API页面卡住 并且无法自行try catch，体验不是很好。
希望可以即使出现执行问题，也可以保证页面正常渲染，和后续的用户操作正常执行，或者给出一个前置的判断函数判断当前参数是否可调用该方法。

您好，SpreadJS作为一个控件只提供相对基础的API，如果您有业务上或者开发上的需求，最好的解决方法是根据您的实际需求结合基础API去进行开发。

比如您的这个需求，您可以再封装一个API，在这个API中先判断要设置合并单元格的区域是否已经存在合并单元格，如果已经存在，则返回您自己的错误提示，如果不存在，则正常设置即可。

可以考虑使用getSpans接口获取区域内的合并单元格：https://demo.grapecity.com.cn/sp ... .Worksheet#getspans

Joestar.Xu 发表于 2024-12-30 11:08
您好，SpreadJS作为一个控件只提供相对基础的API，如果您有业务上或者开发上的需求，最好的解决方法是根据 ...

您好，提出这个问题的问题点在于SpreadJS提供出的API内部产生报错导致页面无法滚动，并且我们业务上无法在try catch的情况下恢复页面可用性，即使本次我们进行了前置判断处理，之后每次调用api之前都需要添加该判断，那么该api是否存在不合理之处？
因此期望该API调用失败的情况下，在内部进行try catch保证页面可以正常使用，则调用方可以进行后续处理，而不是内部导致卡死空白。

您好，正如我之前所述，SpreadJS是一个控件，控件只提供基础的原子化的接口供开发者调用，使用了原子化API导致内部产生报错页面无法滚动的情况，需要您自行在执行相关API前判断参数是否合法。