Fave Operator of the Day
-
logan1337 wrote:
My desire is to have the behavior default to what I mentioned, but still allowing the programmer to explicitly override this for a block of code.
Dereferencing null is an error on the part of the programmer. Careful programmers take steps to avoid making this error - and i'm all for language or library enhancements that make doing so easier. But making the default behavior more forgiving is just adding another pitfall for careless programmers.
logan1337 wrote:
Finally, when I say "silent" I really mean silent from the perspective of the end user, and not so much just because it's annoying as for the fact that it may in fact, render a program completely useless by accident.
You are perfectly free to change the behavior of null reference errors when it comes to end-users. I did. Obviously, the end-user isn't equipped or inclined to do anything useful about it - so make it obvious to them that it's not their fault, it's yours - and then request that they allow a report to be sent enabling you to fix the problem you caused for them. As far as rendering the program useless - there's no guarantee whatsoever that skipping the line that caused the problem wouldn't cause further problems. In fact, it's entirely possible that it will, given that the internal state of the program is not what the programmer writing the code thought it would be.
logan1337 wrote:
By making the default behavior more tolerant, such "accidental" cases would be completely normal.
You know, there has been at least one set of languages and platforms that allowed this: MS BASIC, VB (and derivatives) had the
On Error Resume Nextcommand to put execution of a routine in just such a mode. It made testing and debugging hell. I've wasted more time trying to track down errors distorted or masked by this construct than i care to think about, and to this day it is the primary reason why i detest "classic" ASP development. Errors Are Errors - masking them doesn't make them less erroneous, it just makes them harder to notice. To use an analogy: double-entry bookkeeping is tedious and hard to understand. Yet, it has been popular for many, many years for the simple fact that it makes certain types of errors more obvious. Obvious errors get fixed. Subtle errors often don't.I still get the impression you don't understand my point, because I don't disagree with what you're saying here. Mistakes are mistakes. Granted. I'm not suggesting otherwise. All I'm saying is that I don't like the way that *I* as a programmer am forced to write my program in adherence with the concept that any unexpected condition will throw an exception and therefore must be explicitly handled (i.e. more work for me). In other words, I'm arguing that the way I originally wrote the program was in fact, not flawed, because of my (admittedly incorrect) subconscious disregard for null objects and the refusal to accept the way things are, and that, if my desired mechanism were, in fact, implemented, then there wouldn't BE a problem to begin with. If the call to player.Close() was crucial, even in the case when player is null (or rather, since this is impossible, the best it could do is indicate an earlier problem), then I would either explicitly mark it as such, or observe this in the debugger output. Can you at least grant me that it should be my choice, even if you do not agree with it? :rose: And don't tell me to switch to VB. :mad: :laugh:
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
I still get the impression you don't understand my point, because I don't disagree with what you're saying here. Mistakes are mistakes. Granted. I'm not suggesting otherwise. All I'm saying is that I don't like the way that *I* as a programmer am forced to write my program in adherence with the concept that any unexpected condition will throw an exception and therefore must be explicitly handled (i.e. more work for me). In other words, I'm arguing that the way I originally wrote the program was in fact, not flawed, because of my (admittedly incorrect) subconscious disregard for null objects and the refusal to accept the way things are, and that, if my desired mechanism were, in fact, implemented, then there wouldn't BE a problem to begin with. If the call to player.Close() was crucial, even in the case when player is null (or rather, since this is impossible, the best it could do is indicate an earlier problem), then I would either explicitly mark it as such, or observe this in the debugger output. Can you at least grant me that it should be my choice, even if you do not agree with it? :rose: And don't tell me to switch to VB. :mad: :laugh:
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
logan1337 wrote:
All I'm saying is that I don't like the way that *I* as a programmer am forced to write my program in adherence with the concept that any unexpected condition will throw an exception and therefore must be explicitly handled (i.e. more work for me).
Well, you don't have to. I mean, that's kind of the point of using Exceptions for error handling rather than, say, checking return values or global flags - you can write out the ideal code without regard for error conditions, and then toss in a few high-level handlers and rely on them to just sweep unusual scenarios under the rug. Heck you can totally skip handling errors altogether if you want, and never have to worry about them compounding in the way that, say, C-style return value errors would (one call failing undetected leading to the next call failing because of the previous failure, leading to the next...).
logan1337 wrote:
In other words, I'm arguing that the way I originally wrote the program was in fact, not flawed, because of my (admittedly incorrect) subconscious disregard for null objects and the refusal to accept the way things are, and that, if my desired mechanism were, in fact, implemented, then there wouldn't BE a problem to begin with.
I'll allow that, in your very specific case, that's probably true. But i don't think it's wise to draw from that the conclusion that all or even most null references are harmless and can be safely ignored. In fact, the conclusion i'd draw would be that the system should be designed with deterministic finalization in mind, so that explicitly
Close()ing the player isn't necessary even when the object does exist. And of course it's your choice. That's been my point all along - you're free to implement whatever system you like to avoid null references. If that works for you, then good. But it shouldn't be the general case, the default for everyone. Trust me - that way lies madness.----
...the wind blows over it and it is gone, and its place remembers it no more...
-
logan1337 wrote:
All I'm saying is that I don't like the way that *I* as a programmer am forced to write my program in adherence with the concept that any unexpected condition will throw an exception and therefore must be explicitly handled (i.e. more work for me).
Well, you don't have to. I mean, that's kind of the point of using Exceptions for error handling rather than, say, checking return values or global flags - you can write out the ideal code without regard for error conditions, and then toss in a few high-level handlers and rely on them to just sweep unusual scenarios under the rug. Heck you can totally skip handling errors altogether if you want, and never have to worry about them compounding in the way that, say, C-style return value errors would (one call failing undetected leading to the next call failing because of the previous failure, leading to the next...).
logan1337 wrote:
In other words, I'm arguing that the way I originally wrote the program was in fact, not flawed, because of my (admittedly incorrect) subconscious disregard for null objects and the refusal to accept the way things are, and that, if my desired mechanism were, in fact, implemented, then there wouldn't BE a problem to begin with.
I'll allow that, in your very specific case, that's probably true. But i don't think it's wise to draw from that the conclusion that all or even most null references are harmless and can be safely ignored. In fact, the conclusion i'd draw would be that the system should be designed with deterministic finalization in mind, so that explicitly
Close()ing the player isn't necessary even when the object does exist. And of course it's your choice. That's been my point all along - you're free to implement whatever system you like to avoid null references. If that works for you, then good. But it shouldn't be the general case, the default for everyone. Trust me - that way lies madness.----
...the wind blows over it and it is gone, and its place remembers it no more...
Ok, I can leave it at that. ;P Cheers.
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
norm .net wrote:
Jim Crafton wrote: is there a VB equivalent Who cares
People in jobs that require the use of VB. >.<
-
Ok, I can leave it at that. ;P Cheers.
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
I'm going to have to go ahead and mention that almost 100% of the time the object in question needs to be used for the code to execute properly.
-
Is this just a C# thing or is there a VB equivalent (I'm almost afraid to ask what that monstrosity would look like)?
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
return _cachedItem ButIfIsNothingThenInstead (_cachedItem = GetItem()):)Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use PRE tags to preserve formatting when showing multi-line code snippets
-
Frankly, I am getting tired of null reference exceptions. I just wish C#/.NET wouldn't be so finicky about null references. For example the latest issue I had was with a MediaPlayer object, where I close the (possibly) existing player before starting a new one: player.Stop(); player = new MediaPlayer(); ... But if I haven't already created a MediaPlayer I get a freaking null reference exception. Of course I know that I should know better and test player for null, but my point is I don't CARE if player.Stop() fails, it's not going to aversely affect my function at all anyway, and my argument is that I bet in 80-90% of cases, null reference exceptions that slip through in production code probably would work fine if they were simply ignored, like my example above. Who's with me for demanding that null reference exceptions be ignored by default and only thrown in blocks explicitly marked as such! Lol, just a mini-rant. :P
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
logan1337 wrote:
Frankly, I am getting tired of null reference exceptions.
Your application would be tired of your bugs already.
logan1337 wrote:
player.Stop();
If the object has not been initialized and if we are trying to do something like this, I wish something more than exception should be thrown. Or an exception with the message() returning "What the f*ck to stop?" that would make us bang our head on wall and not to repeat such coding blunder.
logan1337 wrote:
Who's with me for demanding that null reference exceptions be ignored by default and only thrown in blocks explicitly marked as such!
The VB mob. And to tell you the fact, we f*cking damn check against NULL exception at a zillion points in our (scientific) applications. At somecases, by habit we over check something like this .
functionCaller(myobj* pMyObj)
{
try
{
CHECK_NULL(pMyObj); //<--Check one.
myfunction(pMyObj,..);
}
..
}
myFunction(myObj* pmyObj_in,..)
{
try
{
CHECK_NULL(pmyObj_in); //chk2<--which is unnecessary.
}
}Like I said, at first we put the check at every point, but while optimizing the code, we remove the checks if it's found redundant. Sorry for the little rant ;P :)
Jemmy : Deadline? Pfft, a real programmer eats deadlines for breakfast. :P Mark: I thought real programmers ignored deadlines :sigh: Best wishes to Rexx[^]
-
logan1337 wrote:
Frankly, I am getting tired of null reference exceptions.
Your application would be tired of your bugs already.
logan1337 wrote:
player.Stop();
If the object has not been initialized and if we are trying to do something like this, I wish something more than exception should be thrown. Or an exception with the message() returning "What the f*ck to stop?" that would make us bang our head on wall and not to repeat such coding blunder.
logan1337 wrote:
Who's with me for demanding that null reference exceptions be ignored by default and only thrown in blocks explicitly marked as such!
The VB mob. And to tell you the fact, we f*cking damn check against NULL exception at a zillion points in our (scientific) applications. At somecases, by habit we over check something like this .
functionCaller(myobj* pMyObj)
{
try
{
CHECK_NULL(pMyObj); //<--Check one.
myfunction(pMyObj,..);
}
..
}
myFunction(myObj* pmyObj_in,..)
{
try
{
CHECK_NULL(pmyObj_in); //chk2<--which is unnecessary.
}
}Like I said, at first we put the check at every point, but while optimizing the code, we remove the checks if it's found redundant. Sorry for the little rant ;P :)
Jemmy : Deadline? Pfft, a real programmer eats deadlines for breakfast. :P Mark: I thought real programmers ignored deadlines :sigh: Best wishes to Rexx[^]
-
VB Mob refers to the average VB programmers. You are an exceptional VB programmer. :-D .. makes me laugh. Btw, as we discussed, you are a .net programmer. not VB6 progammer. Congrats!
OK,. what country just started work for the day ? The ASP.NET forum is flooded with retarded questions. -Christian Graus Best wishes to Rexx[^]
-
VB days are numbered.
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
I agree - that doesn't mean I don't want to know as many features as possible while I'm working in it.
-
The C# 2.0 null coalescing operator
??God bless its little cotton socks.cheers, Chris Maunder
CodeProject.com : C++ MVP
...Okay I feel stupid. Even with the example, I have no clue what that is doing. I should actually start reading books again instead of fixing and maintaining Fortran and VB code for the rest of the engineers around here.