[Spoon]

I'm stumped. Whenever I try to load a mission (debug build) with certain ships that have animated glow maps on it, I'm greeted by this message:

bm_get_info - : bm_bitmaps[-1].handle = 0, handle = -1
ASSERTION: "bm_bitmaps[bitmapnum].handle == handle" at bmpman.cpp:1087   (<---  this number can vary)
 Invalid bitmap handle -1 passed to bm_get_info().
This might be due to an invalid animation somewhere else.

Well I've checked and double checked whatever animated maps are involved and could see nothing wrong with them. Some of them haven't even been modified since 2010 and I've never seen this assert before.
I've tried several builds (a swifty go_faster build, a valathil shadows build and the latest debug build I could pull from the scp svn) and they all gave me this. Though strangely enough using those builds with WoD1 didn't give me any errors related to this at all. So I have no clue what to look for here.

plz halp

[Spoon]

Welp, never mind.
Turns out this was all related to a single missing hud .ani

Gotta love these vague assertions that completely put you on the wrong thinking track.

[The E]

Well, at that point in the process, the assertion unfortunately can't be more helpful. The point where a helpful error message could be spawned is waaay upstream here.

[Dragon]

The only thing worse than assertions are Int(3) errors, which give no info whatsoever. And despite the fact they're supposed to be errors no coder thought would appear, I've gotten them pretty often, sometimes on such simple mistakes as a missing HUD ani. There's definitely room for improvement here.

[The E]

You may not have noticed this, but there's been an ongoing effort (at least by me) to convert all Assert()s and Int3()s into Assertion()s (which is like an Assert, but allows you to print a more helpful error message).

Also, in those cases, it usually helps to mention this somewhere where a coder may see it.

Oh, and let us not forget that the error reporting in trunk and .14 is infinitely better than what happened in .10

[karajorma]

You may not have noticed this, but there's been an ongoing effort (at least by me) to convert all Assert()s and Int3()s into Assertion()s (which is like an Assert, but allows you to print a more helpful error message).

Well obviously I'm in favour of better error reporting since I added Assertion() in the first place. That said, some asserts already give the coder all the information they need. Although Assertion seems more useful to the modders than Assert, sometimes I doubt it would actually have any more useful information for the coder.

The only thing worse than assertions are Int(3) errors, which give no info whatsoever. And despite the fact they're supposed to be errors no coder thought would appear, I've gotten them pretty often, sometimes on such simple mistakes as a missing HUD ani. There's definitely room for improvement here.

Quite often there's not that much information an Int3() could give. An Int3() is meant to be a "You should never reach this part of the code" error. Sometimes predicting what could have gone wrong so as to reach that part of the code is not easy.

[The E]

You may not have noticed this, but there's been an ongoing effort (at least by me) to convert all Assert()s and Int3()s into Assertion()s (which is like an Assert, but allows you to print a more helpful error message).

Well obviously I'm in favour of better error reporting since I added Assertion() in the first place. That said, some asserts already give the coder all the information they need. Although Assertion seems more useful to the modders than Assert, sometimes I doubt it would actually have any more useful information for the coder.

My personal rule of thumb is, if an assert can be triggered by bad data, it's agood idea to tell the modder what's happening on the assumption that said modder is clueful enough to not just click through the message.

[karajorma]

I agree. It's just that you said you're converting all the Asserts() and Int3()'s and since some Asserts() are basically down to bad code rather than bad data it's hard to imagine that you really could report anything much more useful to the coder than the information already in the Assert().

[chief1983]

I suppose 'all' might have been an overstatement, but since so many asserts _are_ tied to bad data, we're trying to convert all of those at least.

[Iss Mneur]

Some assertions that would be useful to a coder are things like what are the values of the other local variables when the assertion was generated.

Or my personal favourite the (in)famous "x != -1" Assert. So is x: 0, 1, -2?  This is where assertions are good even for coders.

So there really is no reason ever for Asserts or Int3(), beyond the fact that a Int3 is just a crash to desktop unless you have a debugger around.  Even an Int3 as an assertion would be much more useful than just knowing that the value was not on of the three in the case statements above....

[karajorma]

In the case of a boolean or an Int3() at the bottom of a long series of if(x) {y; return;} there might not be much useful data in the Assertion anyway. The reason the Int3() is there is because the coder never imagined it was possible to reach that past of the code anyway. If some of the data that might have failed could conceivably be null (and the earlier code included tests for that) you might not even be able to actually report the values without crashing the game.

I think it very much depends on the situation. In general though, I will agree that an assertion is better as thinking about what kind of values to include in the assertion is in itself a valuable exercise.