i'm talking to a COM object (Microsoft ADO Recordset object). In a certain case the recordset will return a failed (i.e. negative) HRESULT, with the message:
Item cannot be found in the collection
corresponding to the requested name or
ordinal
i know what this error message means, know why it happened, and i how to fix it. But i know these things because i read the message, which fortunately was in a language i understand.
Now i would like to handle this exception specially. The COM object threw an HRESULT of
0x800A0CC1
In an ideal world Microsoft would have documented what errors can be returned when i try to access:
records.Fields.Items( index )
with an invalid index. But they do not; they most they say is that an error can occur, i.e.:
If Item cannot find an object in the
collection corresponding to the Index
argument, an error occurs.
Given that the returned error code is not documented, is it correct to handle a specific return code of `0x800A0CC1' when i'm trying to trap the exception:
Item cannot be found in the collection
corresponding to the requested name or
ordinal
?
Since Microsoft didn't document the error code, they technically change it in the future.
They did document this error code, but it's hard to find:
ErrorValueEnum:
adErrItemNotFound 3265 -2146825023 0x800A0CC1 Item cannot be found in the collection that corresponds to the requested name or ordinal.
..so, as its' a documented error code, it is safe to test for it explicitly.
You'll have to decide whether or not it is worth the risk, but I believe that it is unlikely that Microsoft will change this error code. Checking for this particular error code is a pretty robust way to go.
Yes, it is fine. It is in fact a documented error code, although finding them is never easy. It is defined in the msdao15.idl Windows SDK file, adErrItemNotFound (error 3265)
Related
The documention for git_treebuilder_insert seems to imply that it doesn't care whether the object being inserted is valid:
No attempt is being made to ensure that the provided oid points to an existing git object in the object database, nor that the attributes make sense regarding the type of the pointed at object.
However, when actually using the library to create tree objects, if I try to write an entry with an invalid oid, this function returns failure. As reference, here's the code:
if (filemode != GIT_FILEMODE_COMMIT &&
!git_object__is_valid(bld->repo, id, otype_from_mode(filemode)))
return tree_error("Failed to insert entry; invalid object specified", filename);
What is the intended behavior, the code or the documentation?
The documentation is outdated; the code behaves as expected. The change to validate object pointers was made in order to:
Allow library users to make assumptions about the safety of their projects. It is generally an error to create something that dangles and points to an object that does not exist.
Improve consistency between creating references and creating objects. Now they both validate that the thing(s) they're pointing to exist, by default.
If you do not want this behavior, you can disable it, by calling:
git_libgit2_opts(GIT_OPT_ENABLE_STRICT_OBJECT_CREATION, 0);
I've made a large program that opens and closes files and databases, perform writes and reads on them etc among other things. Since there no such thing as "exception handling in go", and since I didn't really know about "defer" statement and "recover()" function, I applied error checking after every file-open, read-write, database entry etc. E.g.
_,insert_err := stmt.Run(query)
if insert_err != nil{
mylogs.Error(insert_err.Error())
return db_updation_status
}
For this, I define db_updation_status at the beginning as "false" and do not make it "true" until everything in the program goes right.
I've done this in every function, after every operation which I believe could go wrong.
Do you think there's a better way to do this using defer-panic-recover? I read about these here http://golang.org/doc/articles/defer_panic_recover.html, but can't clearly get how to use them. Do these constructs offer something similar to exception-handling? Am I better off without these constructs?
I would really appreciate if someone could explain this to me in a simple language, and/or provide a use case for these constructs and compare them to the type of error handling I've used above.
It's more handy to return error values - they can carry more information (advantage to the client/user) than a two valued bool.
What concerns panic/recover: There are scenarios where their use is completely sane. For example, in a hand written recursive descent parser, it's quite a PITA to "bubble" up an error condition through all the invocation levels. In this example, it's a welcome simplification if there's a deferred recover at the top most (API) level and one can report any kind of error at any invocation level using, for example
panic(fmt.Errorf("Cannot %v in %v", foo, bar))
If an operation can fail and returns an error, than checking this error immediately and handling it properly is idiomatic in go, simple and nice to check if anything gets handled properly.
Don't use defer/recover for such things: Needed cleanup actions are hard to code, especially if stuff gets nested.
The usual way to report an error to a caller is to return an error as an extra return value. The canonical Read method is a well-known instance; it returns a byte count and an error.
But what if the error is unrecoverable? Sometimes the program simply cannot continue.
For this purpose, there is a built-in function panic that in effect creates a run-time error that will stop the program (but see the next section). The function takes a single argument of arbitrary type—often a string—to be printed as the program dies. It's also a way to indicate that something impossible has happened, such as exiting an infinite loop.
http://golang.org/doc/effective_go.html#errors
I have been searching for this all over the web, but everything is either talking about the ErrObject class, or the constant vbError returned by the VarType function. I want to know what that type actually is, e.g. an integer is something like 4, a string is something like "hello world", etc.
For a little background, here is a link to the official MSDN page about VarType, which shows all the constants it returns and what they represent. What is Error value?
If you are familiar with COM in C/C++, you should know that from that perspective VarType() is a simple function that essentially extracts the value of the vt member from the Variant passed in as a parameter. The possible values of the vt member are documented in many places, such as here.
If you check inside of the COM system headers (e.g. WTypes.h distributed as part of in the Windows SDK), you will see that the VbError value of 10 indeed maps to the C/C++ enum value of VT_ERROR.
enum VARENUM
{ VT_EMPTY = 0,
...
VT_ERROR = 10,
...
} ;
The MSDN link above describes the meaning of a vt that equals VT_ERROR as follows:
An SCODE was specified. The type of the error is specified in scode.
Generally, operations on error values should raise an exception or propagate the error to the return value, as appropriate.
So, here's basically what it means:
A Variant obviously supports storing many types of values, and among them is the obscure possibility of storing an "Error Code". More correctly, these codes are formally called scode's, because they can indicate many types of "success" as well as "failures". Most people refer to these codes as HRESULTs.
These codes are the same kind of "Error Codes" that you get from Err.Number in VB6. So, you can tell a Variant to distinguish an "Error Code" from just a plain number.
In reality, few programs or COM components - if any - will ever put error codes in Variants. Almost everybody just issues COM Exceptions to communicate errors (this mechanism is exposed in VB6 via the Err object). Even those components that return error codes outside of the COM Exception mechanism, would likely do so in typed variables (e.g. Long's).
Therefore, the reason this possible return value exists is for completeness. You will almost never see it in real life.
(Edit: Remove bit about not being able to create an "Error" variant. #Joe proved me wrong on that. You can use CVErr() to create one)
In VB6 and VBA, error values are created by calling the CVErr function.
This function returns a Variant whose VarType is vbError, and for which the IsError function returns True.
A typical use case for this is an Excel UDF that returns a Variant: if you return an error value, it will display as #VALUE!.
My error message is as listed in the header "Input string was not in a correct format" however the stack trace is even more cryptic
Microsoft.VisualBasic.CompilerServices.Conversions.ParseDouble(String Value, NumberFormatInfo NumberFormat) at Microsoft.VisualBasic.CompilerServices.Conversions.ToDouble(String Value, NumberFormatInfo NumberFormat)
This is worse due to the fact that nowhere in the project does it use "ParseDouble". I believe that this has something to do with the objectfactorylibrary but can't pin anything down.
Has anyone seen something similar or point me in a general direction?
Edit:
Additional information, this is a production only issue with local, dev, and QA unable to reproduce the error in any environment but Production.
The stack trace is referring to a method inside of the .NET Framework code, called ParseDouble. It does not exist in your code. This is why the entire namespace is included, so that you can tell where the method is defined. If it starts with Microsoft or System, it's not something you wrote.
You probably used the CDbl operator (it's that thing that looks like a function call to the uninitiated), and internally, the .NET Framework translated that to a call to the Conversions.ToDouble method, which internally calls the Conversions.ParseDouble method. These are implementation details that you should not have to be concerned with. Keep traveling up the stack trace until you find the last method called that is part of your code.
As far as why your code is throwing that error, it's almost impossible to say without seeing some code that reproduces it.
However, my psychic debugging powers tell me that you're probably trying to parse a string value into a number, and the method is failing because the string does not contain a valid number. Check the value of the string you're passing into the method and update your question. It's probably an issue of the language settings on your computer. Do you use a language where , (a comma) is the decimal separator rather than . (a period)?
It's basically telling you that you that it tried to convert a string to a number but couldn't as the string was not numeric (could have alpha or other characters in it).
The stack trace should point you towards the offending piece of code, if you're lucky you will have a line number. If this is a piece of code that usually works then take a look at the data (whatever it is).
Today I discovered that something I had assumed about VB.NET for many years was not true (worrying!). I assumed that a variable declared within a loop had a lifetime of the iteration it was declared in, but in fact it seems it has a lifetime of the whole procedure.
For example:
For i As Integer = 0 To 1
Dim var1 As Boolean
Console.WriteLine(var1.ToString())
var1 = True
Console.WriteLine(var1.ToString())
Next
Console.ReadKey()
I had assumed an output of False, True, False, True but instead it is actually False, True, True, True.
In C# the equivalent code would not compile as you would get a compile time error of Error "Use of unassigned local variable 'var1'".
I realise there are many ways to fix this and that best practice would be to declare the variable outside of the loop and reset it at the beginning of every loop through.
I find this behaviour so counter-intuitive to me that I would like at least a compile time warning in VB.NET when/if I do this. (I could also then set this on any projects I already have and get warning that would allow me to check that my assumptions aren't causing errors).
Does anyone know how/if I can get this to generate a compile time warning in VB.NET? Am I the only one that finds this counter-intuitive?
We'll have to work on fixing your intuition because getting an error out of the compiler is not an option. It is partially implemented, you can get this warning:
error BC42104: Variable 'mumble' is used before it has been assigned a value. A null reference exception could result at runtime.
And elevate it from a warning to an error with Project + Properties, Compile tab. However, as the warning message indicates, this is only supported for reference type references, it won't budge for a variable of a value type.
Okay, intuition. If the runtime would implement your desired behavior then it would have to allocate a new variable for each iteration of the loop. Which implies that the number of local variables is bounded only by the number of iterations. This is very wasteful and a very easy trigger for StackOverflowException. The JIT compiler doesn't do this, it re-uses the variable. This happens in C# as well, minus the option of letting you not initialize the value explicitly of course.
Fwiw: I very much agree with you that this is unhelpful behavior. You'll probably find receptive ears at connect.microsoft.com, post your feature request there and the VB.NET team will see it. There has been strong backing from customers as well as within MSFT to make VB.NET and C# feature comparable. If you post a link to your feedback report then I'll be happy to vote it up.