As a nice, one-off BYOND feature, I would like it if instead of the standard "type mismatch" runtime error, it would state what exactly was being done to what.
For instance:
"type mismatch: cannot add string to null"
&c.
ID:134195
 Mar 10 2007, 11:06 pm
|
|
Kaioken wrote:
(But you CAN add a string to null! :P) Sometimes its not plainly obvious, when you have deeply nested functions that pass along different types depending on different situations; I've had to add debugging output myself to figure out what exactly something came out as. I second this. | |
I third this. I've added the same thing to the language I'm currently programming, and it seems to make things much easier to deal with.
| |
I also meant and should've also mentioned that if it isn't obvious at first, a simple easy debug message tells you everything. Therefore those errors are really easy to figure out.
| |
Well, you must not have had complex enough code. It took me an hour of debugging to figure out why I was getting type mismatches because at one point near the top of a hierarchy of seven nested functions, I used "attr" instead of "attributes[attr]".
Honestly, this whole "I'm better than you" mentality you have just bugs the hell out of me. =P | |
Jtgibson wrote:
Honestly, this whole "I'm better than you" mentality you have just bugs the hell out of me. =P And more importantly, its absolutely irrelevant to the feature request at hand. Given the amount of time a game spends in debugging phase, anything to reduce that amount of time significantly is a step in the right direction. | |
I agree. Out of all the runtime errors, this one has got to be my worst enemy. For simple stuff like the problem I had the other day, it's pretty easy to catch. However, I've had to make proc flowcharts to help me debug one once on one of my larger unpublished projects.
Anything that could save me a couple hours of debugging time is greatly appreciated. :) | |
Kaoiken, you've had a type mismatch error reported by a player doing something. You know the line number and file, but you don't know what the state of the game was - the mismatch isn't obvious. You throw a debug statement into your code to test it, but this is a really popular game and a well-used piece of code - the bug is rare. It might be a little difficult to catch.
Basically, if you can get extra information from a proc crash, you really want it. | |
Basically, this info won't really help in that case either. If a certain error is rare (in the general sense, of course), it means the variable at hand is conditionally called with/set (whatever) to an incorrect/inappropriate value. At any case you'd need to track all the times the variable was set/the proc was called with that argument and check if an incorrect value/data type is being used, and if you know to distinguish between data types used in code, this new detail won't really mean much.
Also if you guys note, I've never said this suggestion is bad, as it should be simple to add as well as help the newbs, who again, may have a hard time figuring out datatypes and which ones are used in code. Just saying that this particular runtime error is already usually simple to fix. But hey, you guys like picking on me, and since I don't really care and you must be having fun, go ahead and keep at it. :) | |
Jtgibson wrote:
As a nice, one-off BYOND feature, I would like it if instead of the standard "type mismatch" runtime error, it would state what exactly was being done to what. This could pose some difficulty, as the error message is implemented fairly simply and the myriad ways it can occur would require a lot of changes. (Among other issues, we'd have to have a simple way to format the error message, which under the circumstances is a lot harder than it sounds.) It'd be nice, but it's probably not in our sights for a while. Lummox JR | |
Hi! I don't think we've met, but just so you know, I have a reputation of being "a little slow"... so, let me just test my understandin of your thinking here:
This proposed feature is extraneous to the point of irrelevance because it is possible to figure out the error on your own, as you the coder have created the procedure and were ultimately responsible for all the data that fed into it? | |
Hedgemistress wrote:
Hi! I don't think we've met, Hi. This proposed feature is extraneous to the point of irrelevance [...] First of all, never said it was extraneous to the point of irrelevance. Actually if you read carefully I said it should be added sometime as it would be helpful for newbies to understand their error better. because it is possible to figure out the error on your own, as you the coder have created the procedure and were ultimately responsible for all the data that fed into it? Nope, never said that either. Neither will adding this little detail to the error message let you figure out the error on your own in most cases either, as implied by my previous post(s). Its extraneous because this error is mostly easy enough to fix without having this feature, you can easily (if you can reproduce the error, but I've also said something about that earlier as well as there are more things to that) get this little detail yourself, most of the times simply by looking at your code (provided you're NOT a newbie), which you'll be doing anyway if you're gonna debug it, of course. I have a reputation of being "a little slow"... so, let me just test my understandin of your thinking here No problem. I went slightly in-depth for you, tell me if you understand it now. | |
Kaioken wrote:
Hedgemistress wrote: Wait, it's extraneous, but not to the point of irrelevance? So it's only mostly extraneous, then, and only has the saving grace that it might help newbies? ...this error is mostly easy enough to fix without having this feature, you can easily (if you can reproduce the error, but I've also said something about that earlier as well as there are more things to that) get this little detail yourself, most of the times simply by looking at your code (provided you're NOT a newbie), which you'll be doing anyway if you're gonna debug it, of course. Darn, so close, but you don't get any brownie points for this argument because Jtgibson shot it down already. Indeed it's easy to tell where type mismatches come up in simple code, but in sufficiently complex code it is not. When a var carried through 5 layers of procs has been holding the wrong value all along without your knowing it, diagnosing that can be quite difficult. Thus there is a good use for this feature beyond helping newbies (Hedgemistress is not among them, FYI); the problem is, I don't think it would be easy to implement. I have a reputation of being "a little slow"... so, let me just test my understandin of your thinking here "They don't have sarcasm on Betelgeuse, and Ford Prefect often failed to notice it unless he was concentrating." Lummox JR | |
This turned out to be a lot easier than I thought to implement. As of BYOND 4.0, type mismatch and undefined operation errors will show their arguments, to clarify how the error occurred.
Lummox JR | |
Lummox said:
This could pose some difficulty,/ This turned out to be a lot easier than I thought to implement. Haha. I love how *every* single one of your replies to the suggestion forum is just like taking your car to get repaired. All the mechanics stand around and start breathing in through their teeth: "ooooooh, well, looks nasty, could take a while... it'll cost you an arm and a leg... cash upfront, please.". :P | |
PirateHead wrote:
Sweet! Can we have typesafe lists next? Please? Please? Nope. BYOND has no such facility for strict-typing a list. It'd require radical redesign of the language. Lummox JR | |
Anyway, since the error provides the line it occurred on, its already straightforward if not plainly obvious to figure out what the error is after looking at your code. Though it would probably help the newbs who can't even figure out what "type mismatch" means, and should be pretty simple to make, so good call.