Fix handling of uncaught errors #655
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| const argsLen = message.params.args.length; | ||
| let output: OutputEvent; | ||
| if (argsLen > 3 && message.params.args[argsLen - 1].type === "number") { | ||
| if (message.params.args[0].value === "__RNIDE_INTERNAL") { |
| // We also check if the log is not internal to avoid exposing it as part of | ||
| // application logs. |
There was a problem hiding this comment.
| // We also check if the log is not internal to avoid exposing it as part of | |
| // application logs. | |
| // We filter out logs that start with __RNIDE_INTERNAL as those are messages | |
| // used by IDE for tracking the app state and should not appear in the VSCode | |
| // console. |
| const argsLen = message.params.args.length; | ||
| let output: OutputEvent; | ||
| if (argsLen > 3 && message.params.args[argsLen - 1].type === "number") { | ||
| if (message.params.args[0].value === "__RNIDE_INTERNAL") { | ||
| return; |
There was a problem hiding this comment.
add comment here to explain why we don't do anything with those logs
There was a problem hiding this comment.
isn't this in this explained by this comment?
// We filter out logs that start with __RNIDE_INTERNAL as those are messages
// used by IDE for tracking the app state and should not appear in the VSCode
// console.
There was a problem hiding this comment.
if the log doesn't appear anywhere what's its purpose?
There was a problem hiding this comment.
it appears in metro log feed with type: client_log, can be useful for us to debug when runtime started.
There was a problem hiding this comment.
yes, that's exacly what you should write here to explain why we just return and do nothing with the log.
|
One more thing that comes to my mind here is that you should test this with RN 76 with the new debugger, as it may handle reloads differently compared to old one. |
|
@kmagiera you were right, the debugger creates execution context in a different moment in RN 76, I changed the approach to accommodate both versions. |
| @@ -144,6 +141,12 @@ export class DebugAdapter extends DebugSession { | |||
| case "Debugger.scriptParsed": | |||
| const sourceMapURL = message.params.sourceMapURL; | |||
|
|
|||
| if (message.params.url) { | |||
There was a problem hiding this comment.
this deserves some explanation. what does this check do, how often do we execute onDebuggerReady
This PR fixes the problem with debugger ignoring uncaught errors after reloading JS. Because errors Global Handler was only set on first connection to the debugger it would not be added after reload. The solution was to move the logic of setting the handler to happen on debugger event that is triggered both on first and consecutive application loads.
How Has This Been Tested:
Additional changes:
this PR also hides related internal logging from the users debug console