# Debugging errors in functions (stack traces?)

**URL:** <https://talk.observablehq.com/t/debugging-errors-in-functions-stack-traces/952>\
**Category:** Help\
**Created:** [July 6, 2018, 12:13am UTC](https://talk.observablehq.com/t/debugging-errors-in-functions-stack-traces/952 "2018-07-06T00:13:10Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![joshuahhh](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/joshuahhh/32/795_2.png) [@joshuahhh](https://talk.observablehq.com/u/joshuahhh)\
**Post date:** [July 6, 2018, 12:13am UTC](https://talk.observablehq.com/t/debugging-errors-in-functions-stack-traces/952/1 "2018-07-06T00:13:10Z")

</div>

Suppose in one cell you define:

```
function call (f) {
  return f(10)
}

```

and in another you run:

```
call(3)

```

(See [notebook here](https://beta.observablehq.com/@joshuahhh/errors-in-functions).)

As the output to the second cell, Observable will report

```
TypeError: f is not a function

```

Which is true! But there’s no pointer to where `f` is defined, or where it’s incorrectly being used as a function.

This is a dumb toy example, but I’m running into situations in my notebooks where tracing down where an error is happening is legitimately difficult. Is there some way to get a stack trace? (Other than `try { call(3) } catch (e) { console.log(e) }`?)

(Thanks!)

---

<div class="post-metadata">

**Author:** ![mootari](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/mootari/32/581_2.png) [@mootari](https://talk.observablehq.com/u/mootari)\
**Post date:** [July 6, 2018, 3:53pm UTC](https://talk.observablehq.com/t/debugging-errors-in-functions-stack-traces/952/2 "2018-07-06T15:53:39Z")

</div>

Chrome’s dev tools allow you to halt on caught exceptions (via the pause button that looks like a stop sign). It’s not ideal though, because it will halt on any caught Promise exception (especially with lots of dependencies).

 ![2018-07-06%2017_50_28](https://canada1.discourse-cdn.com/flex030/uploads/observablehq/original/1X/dfcdbd529f50d6ddf98a1b1c562a1669a2ad414a.png)

---

<div class="post-metadata">

**Author:** ![jashkenas](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/jashkenas/32/1778_2.png) [@jashkenas](https://talk.observablehq.com/u/jashkenas)\
**Post date:** [April 27, 2020, 6:18pm UTC](https://talk.observablehq.com/t/debugging-errors-in-functions-stack-traces/952/3 "2020-04-27T18:18:11Z")

</div>

Resurrecting this old thread to mention that Observable now supports tracing the entire call stack through which errors occur, and allows you to jump to the root cause of the error, if it happened in a different cell:

> [@Error Traces](https://talk.observablehq.com/t/error-traces/3167):
>
> Hi folks, We’ve launched some improvements to our tracing of errors that may occur in JavaScript code within notebook cells. Now, when an error happens, Observable should highlight every position in every function call in your notebook through which the error passes. And, if the error originates in a different cell than the one that is calling the function (or referencing the invalid cell), there’s a handy “Jump to error” button that can help you jump right to the root cause. Here’s a little …

---

<div class="post-metadata">

**Author:** ![mootari](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/mootari/32/581_2.png) [@mootari](https://talk.observablehq.com/u/mootari)\
**Post date:** [April 27, 2020, 6:27pm UTC](https://talk.observablehq.com/t/debugging-errors-in-functions-stack-traces/952/4 "2020-04-27T18:27:54Z")

</div>

> [@jashkenas](#):
>
> and allows you to jump to the root cause of the error

Whaaaaaaaaaaaat 😲