The panic I got wasn’t due to using reflection. As to your definition of the function, it’s supposed to be for anyinterface — it has nothing to do with Error.
why do you need to generalize it to interface{} if you need in to work with the concreteError interface? What is the point of static types if you eventually still using reflect or unsafe?
[W]hy do you need to generalize it to interface{} if you need in to work with the concrete Error interface?
Because I prefer general solutions to narrow solutions. Suppose you have not one but N interfaces where N >> 1. Do you really want to write N different functions, one for each interface, that all do the same thing? If so, feel free — in your code-base.
But the actual fix (as I wrote) is not to let the interface become (*MyError,nil) in the first place. I added the Hacks section as a general solution to show it’s possible to check for a nil-valued interface in Go, but I never said it was preferable.
What is the point of static types if you eventually still using reflect or unsafe?
I never said I was using either. Again, the actual fix is as I described. I am not using the functions I described in the Hacks section.
Please read what I actually wrote and do not assume anything I did not write explicitly.
(*MyError,nil) Nil as a value in interface if [sic] a hack of language design
Take it up with the Go authors, not me. I only described the way Go is and what the authors’ rationale for it being that way is. As I mentioned, it does actually have a use. But I'm not going to argue either for or against it — that’s outside the scope of my post.
I admit I have not read your post ...
In general, perhaps actually read posts before commenting on them. Specifically for my posts, you must read them before commenting on them; or please don’t comment on them at all. Thanks for your cooperation.
after seeing the code examples because of obvious reasons.
The panic I got wasn’t due to using reflection. As to your definition of the function, it’s supposed to be for any
interface— it has nothing to do withError.why do you need to generalize it to
interface{}if you need in to work with the concreteErrorinterface? What is the point of static types if you eventually still usingreflectorunsafe?Because I prefer general solutions to narrow solutions. Suppose you have not one but N interfaces where N >> 1. Do you really want to write N different functions, one for each interface, that all do the same thing? If so, feel free — in your code-base.
But the actual fix (as I wrote) is not to let the interface become (*MyError,nil) in the first place. I added the Hacks section as a general solution to show it’s possible to check for a nil-valued interface in Go, but I never said it was preferable.
I never said I was using either. Again, the actual fix is as I described. I am not using the functions I described in the Hacks section.
Please read what I actually wrote and do not assume anything I did not write explicitly.
(*MyError,nil)Nil as a value in interface if a hack of language designI don't think that a good idea to have N different nil interfaces in the first place
I admit I have not read your post after seeing the code examples because of obvious reasons.
Take it up with the Go authors, not me. I only described the way Go is and what the authors’ rationale for it being that way is. As I mentioned, it does actually have a use. But I'm not going to argue either for or against it — that’s outside the scope of my post.
In general, perhaps actually read posts before commenting on them. Specifically for my posts, you must read them before commenting on them; or please don’t comment on them at all. Thanks for your cooperation.
I have no idea what that means.
Absolutely! That's your right sir. I promise I won't ever either read of comment your valuable content.