or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
How much context for async error traces
One of the challenges of the current async await design is that a requirement that a future must be
Send
often comes at some top-level function, where the actual problem that prevents the future from beingSend
occurs in some other function. We're struggling a bit at how much information to present and how in order to best explain what's going on.Simple example: one step
Consider this example (playground):
Currently, it gives the following error:
As the error explains, the problem is reported in the
main
function, but it's caused by the code inasync_fn1
. I think this error is pretty decent, though I'm definitely open to suggestions on how to improve this case.Example with multiple steps
Now consider this case (playground). The only difference is that
main
callsasync_fn3
, which in turn callsasync_fn2
, and ultimatelyasync_fn1
, which has the problem:The error we report in this case is largely unchanged:
The concern
There are two concerns with the error messages here:
main
) and the leaf function (async_fn1
) that caused the error. Users have to intuit the path between them.There is a bit of a trade-off here that we are trying to decide how to resolve. Adding more information makes the message more complex and foreboding, but leaving it out means that users have to figure out.
How to resolve this?
There are a few thoughts on how to resolve this.
Do nothing
We could keep the status quo. After all, if you want to fix the bug, almost always you will do so by altering the code in the leaf function, so it's not that interesting to find the path from the cause of error to the leaf function, and it's usually not that hard to find. @sfackler expressed this opinion in the past (not to put words in their mouth).
Give the full stack trace
At the other extreme, PR #67116 proposed to alter our reporting in these "multi-step" to include the full details for each step along the way. So, for a very similar example, we get output like this:
Minimal notes
A middle ground might be to note the functions in the stack trace, without giving full details (see the final "note" entries at the end), although we might want to show line numbers or some bit of more information as well:
Give user control
We don't presently have an option to request verbose errors. We could add this. I am somewhat skeptical – I think most folks won't know it exists, and I buy into the idea that we should try to tune the defaults to be as useful as we can (without being overwhelming) and avoid adding a lot of knobs. Knobs in particular feel like they will allow us to expend less effort on the defaults and – since most folks won't use them – the overall quality of our errors goes down.
What I would like from you
I'd like to know which of these options you prefer, of course, as well as other alterantives that we may not have considered. But I'm particularly interested in feedback from: