Would it be possible ...

... to make an API that listens for API Script Errors (the same way as your Sandbox does) and dump them to game chat to the GM, and in the same instance provide a button/link following description error - "Restart Sandbox" (the usual fix) - that is coded to a macro (the API makes this first time it starts up) that can restart the API sandbox within game/ not having to open the game's API script page?

I don't believe so. I wanted this (and actual script/line number errors that make sense to help with finding that error, since the scripts are all concat into one big one when ran..making line numbers in errors useless). The best you can do I believe, is what some of The Aarons scripts, and the Pathfinder sheet comp sheet does (and maybe others, they are just the ones I've seen) where you use a catch() in the script to grab the error and send it to chat to let you know, before it can actually crash the sandbox. But once the sandbox is down, you would be in a catch22. No sandbox running for the button you created to run in, to restart it. Sort of like having a man that just passed out, slap himself to wake himself up :) I believe the only true solution to achieve what you want is a suggestion post asking for that to be added to Roll20 itself. Unless some of the way more advanced JS gurus here know a way to do it scriptwise.

Unfortunately, because these errors crash the sandbox there's no global way to do it. Us script authors can however code in handling to prevent these crashes and send the errors to chat. When doing this it is also possible to change the error message to reference the actual script's line number rather than the concatenated line number. Aaron has started doing this in his scripts, and I've got one script (Pathfinder Companion) that does it as well. Heh, ninja'd by DX :) I'll leave this up though as it does have some information about modifying the line numbers referenced in the errors.

DXWarlock said: I don't believe so. I wanted this (and actual script/line number errors that make sense to help with finding that error, since the scripts are all concat into one big one when ran..making line numbers in errors useless). The best you can do I believe, is what some of The Aarons scripts, and the Pathfinder sheet comp sheet does (and maybe others, they are just the ones I've seen) where you use a catch() in the script to grab the error and send it to chat to let you know, before it can actually crash the sandbox . But once the sandbox is down, you would be in a catch22. No sandbox running for the button you created to run in, to restart it. Sort of like having a man that just passed out, slap himself to wake himself up :) I believe the only true solution to achieve what you want is a suggestion post asking for that to be added to Roll20 itself. Unless some of the way more advanced JS gurus here know a way to do it scriptwise. Ok - so what I see there is what I mean.  In other words, you have an API that all it is is a listener for errors.  If it finds one, it quickly compiles an output to send to chat but also includes a link to the macro its made in the global macros list, that can restart the API sandbox without using an API to do it (not sure if a macro can do that with GM/ Pro subscriber level auth though - thats something that probably only an API could do).  Even a spit out of error would be useful to know immediately that there was an error, to help in tracking down its cause.

It'd be even nicer if it knew which API caused the error

You'd have to add it to each of your scripts and wrap the script parts in it.. sort of like an if/then but a try/catch.

ya lost me to that one, but I'll count it as "not possible"

Wolf Thunderspirit said: It'd be even nicer if it knew which API caused the error If you are writing your own scripts, you can see to some degree: Make the whole script a function. Like (very stripped down example): var MyScript = MyScript || (function () { [code stuff] }()); And part of the error will say what 'function' failed. which will be your script. I only have the barest grasp of the whole workings of it, Aaron showed it to me, its how he does all his scripts that I've seen.  If he pokes his head in, or someone else that lurks around here they can explain it better than I.

Try / Catch blocks are very handy when you are having an error. It helps if you have an idea where the code is breaking. You can then do this try { &nbsp;&nbsp;&nbsp;&nbsp; // put your code here, that you wish to test } catch(err) { &nbsp;&nbsp;&nbsp;&nbsp; // if the code fails, it will jump to this step // you can put a log or sendchat statement to print out details about the error // the "err" in brackets above is created, and err.name gives you the error name, and err.message the javascript error message // so for instance: log(err.name + ": " + err.message); return; // you might want to quit the function if an error happens, because running code after this might generate more errors. } To be honest, the error message might be too arcane if you not that experienced with scripting, but it's a start. There's a few more details and an example of it used here:&nbsp; <a href="https://www.w3schools.com/js/js_errors.asp" rel="nofollow">https://www.w3schools.com/js/js_errors.asp</a>

Yeah folks, hate to say it, but I'm nearly code illiterate here.&nbsp; I've finally got my head around macro coding, which is now pretty simple.&nbsp; But it looks like a lot of javascript/ C++ coding that I've long since forgotten how to do (last I worked on websites was about 10 yrs ago, early on when I learned HTML 4.0, css, php, MySQL, and javascript).&nbsp; Haven't used it in years, so often when i look at API code now I can recognize the barest limit of it and determine the language (if I'm even right), but not what is happening. Afraid at my age its easier to ask for help than try to resurect old knowledge and incorporate a decade of progress in said language to create anything myself.&nbsp; With the Diabetes eating its way into the brain, I just don't have the faculty anymore.&nbsp; :-(