Re: my first class - getting an error
- From: Peter Duniho <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Mon, 10 Sep 2007 21:23:06 -0700
Paul wrote:
This is a pet peeve of mine, with respect to the compiler errors. In some cases, in a well-intentioned effort to provide you with additional guidance, the compiler introduces some concept that you may not even be aware of, completely confusing the issue.
This is so true. I recall fondly that older systems have had much more useful compiler and runtime error information. Like the C compiler on a DG Eclipse system. The stack trace was always right on and you could fix a bug in minutes, without usenet!
Well, I was talking about the compiler, rather than the debugger. But yes, I think there are some things the debugger makes more confusing than it needs to be too.
That said, I have never had trouble getting a correct stack trace.
And the manuals were complete and accessible in a nearby book rack.
Oddly enough, I not only use electronic docs for practically everything now, I usually don't even use the local copies, preferring instead to use the web site versions that are almost always available. I keep the local copies around just in case, but the online docs seem more up-to-date, include community comments in some cases (like MSDN doc pages), and tend to be better linked to external resources.
When MSDN came out, my first thought was "I'll never give up my books". But apparently I was wrong. :)
One thing that annoys me about microsoft progamming is they never tell you the variable that caused a null value exception. What would be so hard about that?
Actually, that one seems pretty hard to me. Compilers don't generate symbols matching specific machine instructions to specific variables. So the debugger would have to reverse-engineer whatever machine instructions led up to the null reference in order to identify the exact variable, if any, that caused the exception.
In non-optimized builds it might be a little easier. I'd hate to think what the debugger would have to go through to figure things out in an optimized build.
My usual solution is to just look at the variables involved, and if one is null when it shouldn't be, I've found the culprit. Not too hard. :)
And the time saving would be enormous. They never seem to build on the knowledge of past technology and how good some parts of it were.
I've never seen a debugger that told me exactly what variable had the invalid data that led to an exception. That doesn't mean they don't exist, but I wouldn't call that a standard feature, even in "past technology".
You can just call the addition like this.
double c = Summing.CalculateSum(a, b);
public class Summing
{
public static double CalculateSum(double a, double b)
{
return a + b;
}
}
It wouldn't work way you have it since the arguments are incorrect.
Heh...funny thing is I thought about suggesting the method be static, and then thought "I just railed about confusing newbies with more information than they really need at the moment", and figured I'd better leave that out.
But if I had, I might have looked at the code closely enough to notice that extraneous "out" parameter that you picked up on. :)
Pete
.
- References:
- my first class - getting an error
- From: vinnie
- Re: my first class - getting an error
- From: Peter Duniho
- Re: my first class - getting an error
- From: Paul
- my first class - getting an error
- Prev by Date: Re: ListBox.Items change event?
- Next by Date: Re: lock on filename for XmlDocument.Save?
- Previous by thread: Re: my first class - getting an error
- Next by thread: Re: my first class - getting an error
- Index(es):
Relevant Pages
|
