为什么run返回的promise都得是resolved呀

[taterboom]

https://github.com/umijs/hooks/blob/e27e65ba7b9ea5f8a343f959b0f174b3e0ee7b59/packages/use-request/src/useAsync.ts#L151

[Malarkey-Jhu]

求问 +1

[Malarkey-Jhu]

比如在一个event handler (function body)里面，想对run 返回的错误进行处理，如能返回reject就好了

[brickspert]

现在可以通过 onError 来处理。

[Malarkey-Jhu]

是这样的，handler里面，还有要根据run 的执行结果成功与否再进行其他事情，这种情况下onError没法暂停執行或抛出错误

[Malarkey-Jhu]

不过都返回resolved是有什么设计上面的考量吗 (好奇

[brickspert]

我记得最早是因为请求报错后，用户不希望自己 catch ，才改成 return 的。

如果改成了 throw，所有的 run 都需要用户自己去 catch，似乎不是很好。满屏都是

run().catch()

[brickspert]

我测试了下，给个最终的解释：如果改成 throw，则每个 run 都需要 catch，否则会出问题。

如下示例，如果改成 throw，不 catch 的情况下会白屏。

function getNumber() {
  return Promise.reject(new Error('some error'));
}

export default () => {
  const { data, loading, run, error } = (() => getNumber(), { manual: true });

  return (
    <>
      <Spin spinning={loading}>Number: {data}</Spin>
      <Button onClick={run} style={{ marginTop: 16 }}>
        fetch
      </Button>
    </>
  );
};

[douxc]

@brickspert 这样的话有个问题：
request的responseInterceptors中判断status、code，给出了统一的处理和错误提示（根据业务code决定），错误的时候会reject。手动run的时候，就要再次判断返回的值是否合法

[brickspert]

@brickspert 这样的话有个问题：
request的responseInterceptors中判断status、code，给出了统一的处理和错误提示（根据业务code决定），错误的时候会reject。手动run的时候，就要再次判断返回的值是否合法

我需要再处理下这里的逻辑，先打开问题。我想下~

[dumeng-chn]

刚刚被这个小小的坑了一下，觉得这里不太符合逻辑。

[douxc]

或许可以再加一个配置catcherror？默认情况抛出异常？

[brickspert]

或许可以再加一个配置catcherror？默认情况抛出异常？

现在有一个 throwOnError 配置，设置为 true，就会把异常抛出来。

[brickspert]

v2.1.0 已经修复了改问题。

• 默认报错不会触发 run().then() 了
• 通过配置 throwOnError 可以正常拿到异常。

[haoqi0818]

@brickspert 我觉得你前面说的有道理呀，满屏都是run().catch() 本身也是个问题。虽然只有 throwOnError=true才会抛异常，但返回Promise.reject()满控制台的Uncaught (in promise) 也是问题呀，还是认为异常没被手动处理。

但正常思维，如果我传了options.onError，应该视为出现的error在onError里处理好了吧。如你所说 promise.catch().then()肯定会执行