Do not use the ObjectInspector for Error rep

[Nicolas Chevobbe]

When a user log an Error object, I'm pretty sure that what they want 99% of the time is to have the error message and a meaningful and actionable stacktrace.

Thus, I think we should not render Error wrapped in an ObjectInspector unless the user deliberately asks for it.

For the custom formatters work, I was thinking we could have an "enhanced" icon. Basically it would be something that would tell you that a special treatment was applied to the object, and let you switch to the "raw" version if you want to inspect the object.

So here we would have the nice stacktrace

✨ Error: "A complicated message"
      λ a   script.js:23
      λ b   script.js:3

And if you hover the ✨ you'll have a "this is an enhanced version of the logged object. Click to see it raw" (need better wording).

And then, on click, we give the user:

▶︎ ✨ Error: "A complicated message"

which only show the error class and message. The user can then expand it to access columnNumber, stack, …

▼ ✨ Error: "A complicated message"
 |      columNumber: 23
 |      fileName: "script.js"
 |      lineNumber: 23
 |      stack: "…"

And I think we should force this view when the Error object is in another object (array, object, map, …).

Here the downside is that the ✨ is right next to the expand arrow, and I guess it could cause mis-clicks.

@violasong what do you think of this ?

[Victoria Wang]

Hi! So, it looks like what currently happens is: an error message and stack trace are shown, with disclosure arrow to expand the raw object?

If so, I'm confused as why this extra step of switching to raw mode is needed, since the disclosure arrow takes as much room as an "enhanced" icon would take, unless...

• Maybe we want to be able to click on a file name in the stack trace to jump to debugger? Chrome does this. We could solve this by only triggering the expand action when clicking the arrow icon, so the rest of message could have different click targets.
• Is this causing annoyance with people accidentally clicking on it? Solution in previous point would help here too

[Nicolas Chevobbe]

@violasong sorry, I think I wasn't clear enough.

Here's what have today in Reps when you log an error object (it's a bit different from what we have in the console):

▶︎ Error: bar
    λ handleLog                    console-test-app.html:215:34
    λ EventListener.handleEvent*   console-test-app.html:119:7

Clicking on the location (console-test-app.html:215:34) would take you to the debugger after #956.

If you click the error message, or the arrow, since we are dealing with an object, we show the object properties. Doing so, we also hide the formatted stacktrace:

▼ Error
|    columnNumber: 34
|    fileName: "https://nchevobbe.github.io/demo/console-test-app.html"
|    lineNumber: 215
|    message: "bar"
|    stack: "handleLog@https://nchevobbe.github.…"

---

My proposal here is to not show the expand arrow by default to the user, since they might only care about the message and the stacktrace.
But, some people might be interested in seeing the internals of such object, and this is where we need to find something to give them the ability to see those properties.

Currently, the expand arrow serves this purpose, but I find this confusing:

• In the console, when an exception is thrown, the arrow before the error message allow the user to show/hide the stacktrace (click on the "Exception" on my test app)
• we might in the future need this "show raw" button for inspectable objects when we implement custom formatters (a way for a library to tell the console how to print an object. See Bug 1262914)

The ✨ icon I propose is meant for this, but I know it's not ideal. Instead we could:

• have a context menu
• put an entry in a possible overflow menu (see #834).

I hope it's more clear now, feel free to tell me it's not :D

[Nicolas Chevobbe]

For what it's worth, both Chrome and Safari does not let you inspect the error object and print similar things than when throwing an exception.
I think we can move on and render Errors as Reps and not ObjectInspector, without the "✨" button proposal (which we can revisit later)

[Victoria Wang]

Hi Nicolas, sorry I stopped responding to this! I think you explained it well - I was just having a hard time wrapping my mind around the concepts, so the notification email languished in my inbox for a while 😅

Your idea to render as Reps for now sounds good, since it sounds like people rarely need the raw object info. In the future, we can use a contextual menu + meatball menu (•••) for this and overflow actions.