Valhalla Legends Archive

Everytime I try to logon with a voided/muted key I get RunTime '5'.

I decided it was most likely something I messed up in the code so I dug out an older version that used to allow voided/muted keys to login but I get the same error, did Battle.Net recently change something with these keys?...Maybe some new packet?

Why don't you try debugging first?

Gogo error handling.

Quote from: Soul Taker on August 18, 2003, 12:22 AM
Gogo error handling.

Note that this does not include the following:On Error Resume Next

Quote from: Skywing on August 18, 2003, 08:01 AM

Quote from: Soul Taker on August 18, 2003, 12:22 AM
Gogo error handling.

Note that this does not include the following:

Code Select Expand

On Error Resume Next

Of course not.  That's not really error handling at all!

Quote from: Soul Taker on August 18, 2003, 09:54 AM

Quote from: Skywing on August 18, 2003, 08:01 AM

Quote from: Soul Taker on August 18, 2003, 12:22 AM
Gogo error handling.

Note that this does not include the following:

Code Select Expand

On Error Resume Next

Of course not.  That's not really error handling at all!

Yes, but I've seen it far too many times in code snippets people paste here while asking for help.

I've tried that, I'm not exactly sure what else I could put for the debuggin, I've made it MsgBox the error number & it's description, It's under the parse, I'm not sure exactly what is wrong, I'll go try & make it more specific.

Isnt RunTime error 5, "Index out of range"? Check your indexes  

The best way is to set a Breakpoint, then reproduce the problem.

Quote from: Skywing on August 18, 2003, 11:39 AM

Quote from: Soul Taker on August 18, 2003, 09:54 AM

Quote from: Skywing on August 18, 2003, 08:01 AM

Quote from: Soul Taker on August 18, 2003, 12:22 AM
Gogo error handling.

Note that this does not include the following:

Code Select Expand

On Error Resume Next

Of course not.  That's not really error handling at all!

Yes, but I've seen it far too many times in code snippets people paste here while asking for help.

Oh why is this not error handling?

On Error Resume Next          'next line breaks a lot, handle locally:
lRet = StupidObject.BrokenMethod( Param1, Param2 )
Select Case Err.Number
Case 0                  'no error.  first so code immediately continues
Case 5                  'contingency for Invalid procedure call or argument
Case 9                  'handle Subscript out of range
  LogIt "MySub", "StupidObject.BrokenMethod", Erl, Err.Number, Err.Description
Case Else             'any other error is ok
   GoTo MyAttachMethod2
End Select

"On Error Resume Next" is perfectly acceptable as a local error handler.  It is not as useful as a procedural, module, or project-level error handler.

Quote from: Grok on August 20, 2003, 06:25 AM
Oh why is this not error handling?

Code Select Expand

On Error Resume Next          'next line breaks a lot, handle locally:
lRet = StupidObject.BrokenMethod( Param1, Param2 )
Select Case Err.Number
Case 0                  'no error.  first so code immediately continues
Case 5                  'contingency for Invalid procedure call or argument
Case 9                  'handle Subscript out of range
  LogIt "MySub", "StupidObject.BrokenMethod", Erl, Err.Number, Err.Description
Case Else             'any other error is ok
   GoTo MyAttachMethod2
End Select

"On Error Resume Next" is perfectly acceptable as a local error handler.  It is not as useful as a procedural, module, or project-level error handler.

I suppose there are a few limited cases where it might be acceptable to use it, but it's far overrused from what I can tell.
It also makes code harder to understand -- no well defined error handler parts -- and forgetting to unset Resume Next may cause annoying, hard-to-debug problems later on in the procedure.  At least if you use a specific error handler label, it's obvious that an (unexpected) error happened, instead of it being "silently" ignored.

Quote from: Skywing on August 20, 2003, 08:06 AM
I suppose there are a few limited cases where it might be acceptable to use it, but it's far overrused from what I can tell.
It also makes code harder to understand -- no well defined error handler parts -- and forgetting to unset Resume Next may cause annoying, hard-to-debug problems later on in the procedure.  At least if you use a specific error handler label, it's obvious that an (unexpected) error happened, instead of it being "silently" ignored.

Actually I see On Error Resume Next as a rather nice way of handling errors - it makes VB work like VC. You get to check for errors in Err kind of like how you in VC check for errors in GetLastError()...

I'll offer to teach a compsci course for the good of the forum...

"VB Debugging 101"