Difficult to debug errors caused by my code but thrown by abstracted scripts

As a developer, it’s difficult to debug errors caused by my code but thrown by abstracted scripts. For example, when I call a third-party module asking it to generate a zombie with ‘Aggresive’ (note typo) BehaviorType, I’ll get a generic, unintelligible error like “Attempt to index nil value” and have to hunt through that developer’s code to find out what’s going wrong. The developer can guard against this and add something like:

assert(behaviorTypes[behaviorType], “BehaviorType '”…tostring(behaviorType)…"’ does not exist.")

so now it’s immediately clear why the error is being triggered, saving me the need to dig through someone else’s code only to find it’s my own fault. Unfortunately, the abstracted script still shows up in the stack trace for the error, making it difficult to track down where my script is causing the issue. Even worse, if the abstracted script is more than 5 scopes deep (stack trace max size), I won’t be able to tell where my script is causing the problem at all.

If Roblox were able to address this, I would be able to identify and resolve bugs in my code more quickly. It would be nice if there was some way to push the stack trace start from a thrown error back by an arbitrary amount. The second argument of error() sort of does this, but it only affects the line shown by the red error text – not the stack trace.

Current:

Ideal:

Code:

Script:

local m = require(script.FreeModelMobCreator)

m:CreateEnemy("Aggresive")

FreeModelMobCreator:

local behaviorTypes = {
	Aggressive = true;
	Passive = true;
}

function assertValidBehaviorType(behaviorType)
	if not behaviorTypes[behaviorType] then
		error("BehaviorType 'Aggresive' does not exist.", 3)
	end
end

local module = {}

function module:CreateEnemy(behaviorType)
	assertValidBehaviorType(behaviorType)
	
	print("Created")
end

return module

Caveats:

  • Will need Studio/dev console settings to change error verbosity so the stack trace does/doesn’t (default doesn’t) show the levels the developer specified to ignore, in the event there’s actually an issue with the abstracted code
  • Would this address issue of an error thrown > 5 stack trace levels inside abstracted script not showing trace past that for the code that actually causes the problem?
  • Will this work with just error, or assert as well?
4 Likes

TL;DR:

  1. Add option for stack tracebacks from errors to respect level argument.
  2. Add option to specify maximum number of levels to display in the traceback.

Yes?

  1. Yes
  2. Maybe. If it’s just a display issue (i.e. only 5 levels are displayed for UX reasons), then it shouldn’t be needed since 5 would be displayed from my script, but if it’s due to only 5 levels being stored at any given time due to memory/etc then yeah