SQLResultEvent not handled

robohelp also throws the same error

just adding all queen stuff here…

got this exception:

java.lang.ArrayIndexOutOfBoundsException: 1

at twcore.bots.twdbot.twdbot.commandAddMIDIP(Unknown Source) at twcore.bots.twdbot.twdbot.handleEvent(Unknown Source) at twcore.core.net.GamePacketInterpreter.handleChatMessage(Unknown Sourc

e)

at twcore.core.net.GamePacketInterpreter.translateNormalPacket(Unknown S

ource)

at twcore.core.net.GamePacketInterpreter.translateGamePacket(Unknown Sou

rce)

at twcore.core.net.ReliablePacketHandler.handleReliableMessage(Unknown S

ource)

at twcore.core.net.GamePacketInterpreter.translateSpecialPacket(Unknown

Source)

at twcore.core.net.GamePacketInterpreter.translateGamePacket(Unknown Sou

rce)

at twcore.core.Session.run(Unknown Source)

also receiving plenty of these:

Jun 19, 2007 11:59:32 AM twcore.core.sql.SQLConnectionPool query WARNING: Slow query (exceeded 2000 ms): SELECT * FROM tblWarnings WHERE name = " god0fdeath" ORDER BY timeofwarning DESC

might need to add an index to the database or clean it up

SQLResultEvent event not handled; ignored probably solved by changeset:1588 but in a different bot then mentioned by lnx - RoboHelp.

The warning about tblWarnings is probably because the table is so big and makes the mysql server slow (or any other process is hogging the mysql server in that case).
I will remove all the warnings of more then a year ago which will clean things and probably speed things up (along with the matchbotlog table).

TODO: finding out and fixing the ArrayIndexOutOfBoundsException.

King's getting that SQL error all the time as well. I'd do something but I know very little about DBs.

Added exception fix for TWDBot. It was printing a stack trace when receiving incorrect formatting, while sending nothing to the user. (I think Ikrit coded this one?) Now just PMs the user with syntax info. Also added NOP handling of SQLResultEvent.

No clue which TWBot module is causing the unhandled SQLResultEvent. A reference search for both of the potentially non-null-id background SQL query methods shows nothing in TWBot (and nothing that doesn't use a null id in TWDBot). The core shouldn't distribute anything with a null id, so I'm not sure where this is coming from… maybe an old residual module?

Jinx on ticket, Mav. :>

Good work on the TWDBot fixes.

Too bad the exception fix is one ugly hack (catch(Exception) already is). Maybe an idea to specifically check for the correct syntax (null check probably) and PM + return if it's not ok instead of a try {} catch(Exception) ?

Replying to dugwyler:

Jinx on ticket, Mav. :>

Jinx?

While I'll agree with you that just wrapping everything in a blanket try-catch Exception block is not a great way to go — it's certainly a good bit slower to process — it's not entirely a hack. The way that the original coder wrote this method is using static accesses of array indices without checking array length beforehand. Because some parameters may be omitted for !add, it's pretty clear that sometimes these arrays will not have an index 1. This means that the coder is relying on the try-catch to catch an exception he/she knows will be thrown sometimes, rather than handling it beforehand. Not the cleanest method, but then again, we do it all the time when we convert part of a String to an Integer, without running Character isDigit() checks to make sure each char of the String is numeric. In some cases just throwing the exception may be slightly faster; at the very least cleaner code-wise, and sacrificing only a few extra cycles for a few less lines of code.

A null check is also made in the code already, as you recommend, because this method was throwing NPEs from time to time if I recall correctly.

I don't think it matters too much about catching a specific kind of Exception vs. the generic Exception itself unless we're planning on having to catch many different exceptions and handle them each differently. Though again, to bring back your original point, yes, if it's clear and simple to check for bad input without a try-catch block before trying anything like number formatting, static accessing of array indices that are not guaranteed to exist, or accessing a potentially null instantiation, by all means it should be done. And if try-catch is used, it should be limited to as small a block of code as possible.

(Also, jinx is a term used by young kids in the US when two people say the same thing at the same time — though it doesn't work quite as well on the internet, haha.)

haha ok very well

Seems like everything in this ticket is fixed, closing the ticket.