[Suggestion] Use recoverable exception instead of directly call exit

[jxlpzqc]

I am the author of TMSpeech, I found when using some corrupted models, the whole process will crash. After investigating this issue, I found there are numbers of exit() in this library, like following:

我是 TMSpeech 的作者，我发现当使用一些损坏的模型时，整个进程会崩溃。在调查这个 bug 的过程中，我发现这个库中有很多 exit()，如下所示：

sherpa-onnx/sherpa-onnx/csrc/online-recognizer-impl.h

Lines 42 to 48 in 86b1856

	virtual std::unique_ptr<OnlineStream> CreateStream(
	const std::string &hotwords) const {
	SHERPA_ONNX_LOGE("Only transducer models support contextual biasing.");
	exit(-1);
	}

But as a underlying library, it may be better to return a error code or throw an exception in this situation where the program can be recovered from the error. Besides, it is implemented in core layer c++ code, and maybe impact users of all language bindings, especially app developer using in-process model.

但作为底层库，在这种程序可以从错误中恢复情况下，返回错误代码或抛出异常可能会更好。除此以外，这段逻辑是在核心层 c++ 代码中实现的，可能会影响使用了任何 binding 的用户，特别是采用进程内托管模式下的应用程序开发者。

[csukuangfj]

请解释什么是损坏的模型？

[jxlpzqc]

谢谢您的回复，损坏的模型指的是不能正常工作的模型，比如下载到一半截断的模型文件，或者 streaming 识别器读取了 non streaming 模型。

[csukuangfj]

这种是不是没有抢救的必要了？

你可以在外部验证模型的大小，或者md5

[jxlpzqc]

确实，我本想提一个PR的，但是简单评估一下，感觉涉及的工作量确实巨大，因为涉及错误码的返回可能涉及修改 c 导出的函数签名，所有的语言绑定都需要修改。

[jxlpzqc]

但是感觉作为一个 lib，直接 exit 确实有点奇怪。

[csukuangfj]

建议在app端做。你用到哪几个模型，就校验哪几个

[jxlpzqc]

对，我这里的问题相对来说比较好解决。

但是我 grep 了一下，发现还存在大量 exit 调用，这些 exit 会不会是一旦出现其他的任何异常，直接退出进程呢？

[csukuangfj]

正常情况下，不会出现的。