adding loc to the runtime report

ID:1939165
 
Sep 20 2015, 7:00 pm
Resolved
usr.loc and src.loc have been added to runtime error details, when they are movables.
Applies to:Dream Daemon
Status: Resolved (509.1303)
This issue has been resolved.
It would be amazing to see the loc (even if null) in the runtime log of an object, for example:

runtime error: Cannot execute null.get reagent amount().
proc name: get fuel (/obj/item/weapon/weldingtool/proc/get_fuel)
source file: tools.dm,287
usr: null
src: welding tool (/obj/item/weapon/weldingtool/hugetank)
loc: space (18,226,2) (/turf/space/transit) <--------- what im asking
call stack:
blahblahbahlbahl()
Sep 27 2015, 3:12 pm
runtime error gives you the exact line of the specific source file. When you get an error, you should be looking at the code, not the map. The location where it occurs is unnecessary and redundant.
Sep 29 2015, 8:54 am
In response to Konlet
With bugs, a lot of factors can cause it, one of those factors is the map.
Sep 29 2015, 11:38 am
Although I think in a lot of games src.loc might not be all that useful, I suspect it could be helpful for some. For instance if an area is supposed to trigger an event in Entered(), it might not be immediately clear where the trouble is happening without loc info. However I wonder if usr.loc would be of even more use, or if both should be included.
Sep 29 2015, 3:25 pm
Personally I would probably only care if loc is null or not, although it might matter if it's a turf or a /movable. But which turf type or even location, probably not so much.

Maybe this could be an expansion of exceptions?
Sep 29 2015, 3:55 pm
It's easier to just throw that info into the exception.desc where it would have gone without exceptions anyway.
Sep 30 2015, 5:38 pm
I would really appreciate this as well, both loc and usr.loc would be quite helpful. If too much information would bloat error logs or if some just don't need it what about some verbose switch somewhere to get regular or detailed errors?
Sep 30 2015, 5:44 pm
In response to MagicMountain
That's already a thing; it's the "exception.desc" that Lummox just referenced.
Sep 30 2015, 6:10 pm (Edited on Sep 30 2015, 6:27 pm)
In response to Konlet
Konlet wrote:
That's already a thing; it's the "exception.desc" that Lummox just referenced.

Could you be more specific? I feel like we're talking about different things, what exactly is exception.desc?


edit, nevermind, found it. I didn't even know BYOND has try/catch now. Awesome.

The desc value is added if and only if this is a regular runtime error and world.Error() handles it; it's pointless overhead otherwise. (The desc info will behave just like current info, where after a number of runtime errors it'll get less verbose and finally stop filling in altogether.)

It looks like desc just holds the detailed text about the error. Trimming the info when a bug repeats like it does is a really good idea but that's not what I meant.

What I'm talking about is some way to switch between the current exception.desc and a more detailed desc with this new loc information and any other helpful bits that might be added to exceptions in the future. That way people can choose to ignore the new stuff if they don't need it.

Like others have said you don't always need to care about loc to deal with a problem but sometimes you hit a tricky one and want to know more.
Sep 30 2015, 6:38 pm
I haven't tested the change yet, but I'm planning on adding this in the next release.
Sep 30 2015, 6:38 pm (Edited on Sep 30 2015, 6:45 pm)
guys. it's really easy.

mob/verb
    runtime()
        var/x = 0
        world << "[1/x]"
    toggle_verbose_runtimes()
        more_verbose_runtimes_pls = !more_verbose_runtimes_pls
        src << "verbose logging is [more_verbose_runtimes_pls? "on" : "off"]"

var
    more_verbose_runtimes_pls = 1

world
    Error(exception/exception)
        if(more_verbose_runtimes_pls)
            var/atom/t = usr
            while(t)
                exception.desc += "[t].loc: " + (t && t.loc?"[t.loc] ([t.x],[t.y],[t.z]) ([t.loc:type || null])\n" : "null\n")
                t = t.loc
        ..()


(for whatever reason, runtimes as a whole do not have a line break at the end, it seems to be part of exception.desc itself, so I add \n)

outputs:
runtime error: Division by zero
proc name: runtime (/mob/verb/runtime)
  source file: IsBanned_test.dm,20
  usr: Super Saiyan X (/mob)
  src: Super Saiyan X (/mob)
  call stack:
Super Saiyan X (/mob): runtime()
Super Saiyan X.loc: The turf (2,4,1) (/turf)
The turf.loc: The area (2,4,1) (/area)
The area.loc: null


If anything, it might make more sense for the exception to contain an actual reference to the erroring object. Either in \ref format, or whatever. Because, obviously it's not going to be usr in every case.
Sep 30 2015, 6:48 pm (Edited on Sep 30 2015, 6:55 pm)
In response to Super Saiyan X
Lummox JR wrote:
I haven't tested the change yet, but I'm planning on adding this in the next release.

Nice!

Super Saiyan X wrote:
guys. it's really easy.

Nice! But that's just usr's loc, the src at the time the error occurred isn't accessible in world/error.

edit:
Super Saiyan X wrote:
world/Error() exists for the very reason the OP created the topic - it'd be better to expand it so it contains either a hard or soft ref to the erroring object, rather than adding loc, or a 'verbose' mode. That's too specific for the variance in BYOND projects.

Now that you mention it a ref to that src in /exception would be even more powerful. You're absolutely right.
Sep 30 2015, 6:52 pm
In response to MagicMountain
MagicMountain wrote:
Super Saiyan X wrote:
guys. it's really easy.

Nice! But that's just usr's loc, the src at the time the error occurred isn't accessible in world/error.

Super Saiyan X wrote:
If anything, it might make more sense for the exception to contain an actual reference to the erroring object. Either in \ref format, or whatever. Because, obviously it's not going to be usr in every case.

world/Error() exists for the very reason the OP created the topic - it'd be better to expand it so it contains either a hard or soft ref to the erroring object, rather than adding loc, or a 'verbose' mode. That's too specific for the variance in BYOND projects.
Sep 30 2015, 7:19 pm
In response to Super Saiyan X
You make a good point. To update /exception that way might need a major build update though.
Oct 1 2015, 3:13 pm
Lummox JR resolved issue with message:
usr.loc and src.loc have been added to runtime error details, when they are movables.
Oct 2 2015, 6:27 pm
should I start a new feature request for a ref to src (probably a safer reference to usr than the proc var) in the /exception datum?
Oct 2 2015, 6:44 pm
In response to Super Saiyan X
Yeah, that would be good. Anything like that will have to wait for 510.
Oct 3 2015, 12:12 am
I hope you aren't tired of hearing this but thank you so much, you've already improved this platform beyond (heh) my wildest dreams. I can't wait to see what else you'll make.
Oct 4 2015, 7:17 am
thanks fam