Make sure to call Dispose()!!!



  • Here's a rare gem of C# found in production code (denatured to protect the guilty):

    Thingie myThingie = yadayada.getAThingie();
    if (myThingie == null)
    {
        // throw exception, Thingie unavailable
        myThingie.Dispose();
        throw new Exception("Thingie unavailable.");
    }
    

    With C# "disposable" instances, you need to make sure to call Dispose, NPE be damned!

    Thank goodness for the helpful comment, however, or I would have been totally at sea.



  •  Of course, I assume that dispose() also checked for null an threw an exception? I hope whoever wrote dispose() remembered to dispose() of objects before calling exceptions.Wouldn't want to avoid endless loops of anything.



  • @robbak said:

     Of course, I assume that dispose() also checked for null an threw an exception? I hope whoever wrote dispose() remembered to dispose() of objects before calling exceptions.Wouldn't want to avoid endless loops of anything.

    ((IDisposable)null).Dispose();

    What, exactly, do you think would happen if you execute that statement?



  • Well since myThingie is null, it doesn't have any methods at all, so myThingie.Dispose() will throw an exception. Dispose() can't check for null because Dispose() won't be found on a null object.



  • @mott555 said:

    Well since myThingie is null, it doesn't have any methods at all, so myThingie.Dispose() will throw an exception. Dispose() can't check for null because Dispose() won't be found on a null object.

    Not really... All methods in.Net are static. The only difference are "instance" methods, like "Dispose" which have a special method signature that pass in "this"... So technically, you can call Dispose on the null object as long as it doesn't use "this" in the method body and it won't throw a null reference exception.



  • @C-Octothorpe said:

    @mott555 said:

    Well since myThingie is null, it doesn't have any methods at all, so myThingie.Dispose() will throw an exception. Dispose() can't check for null because Dispose() won't be found on a null object.

    Not really... All methods in.Net are static. The only difference are "instance" methods, like "Dispose" which have a special method signature that pass in "this"... So technically, you can call Dispose on the null object as long as it doesn't use "this" in the method body and it won't throw a null reference exception.

    Eh, no. The program will choke as soon as there is an attempt to de-reference "myThingie". "mot555" is right.

    And sorry to be opaque, but that in fact was the original point I was trying to make.



  • @rstinejr said:

    @C-Octothorpe said:
    @mott555 said:

    Well since myThingie is null, it doesn't have any methods at all, so myThingie.Dispose() will throw an exception. Dispose() can't check for null because Dispose() won't be found on a null object.

    Not really... All methods in.Net are static. The only difference are "instance" methods, like "Dispose" which have a special method signature that pass in "this"... So technically, you can call Dispose on the null object as long as it doesn't use "this" in the method body and it won't throw a null reference exception.

    Eh, no. The program will choke as soon as there is an attempt to de-reference "myThingie". "mot555" is right.

    Shit, my bad... I confused it with extension methods.



  • @C-Octothorpe said:

    @rstinejr said:
    @C-Octothorpe said:
    @mott555 said:

    Well since myThingie is null, it doesn't have any methods at all, so myThingie.Dispose() will throw an exception. Dispose() can't check for null because Dispose() won't be found on a null object.

    Not really... All methods in.Net are static. The only difference are "instance" methods, like "Dispose" which have a special method signature that pass in "this"... So technically, you can call Dispose on the null object as long as it doesn't use "this" in the method body and it won't throw a null reference exception.

    Eh, no. The program will choke as soon as there is an attempt to de-reference "myThingie". "mot555" is right.

    Shit, my bad... I confused it with extension methods.

    Yeah, and I should have caught that "Dispose" certainly is not static -- it's the programmer implementation of gracefully handling resources like file handles and database connections, and it is absolutely instance specific.

    Guess I had a case of early morning brain farts. My bad.



  • Why do we care about this meaningless trivia? Go build software.



  • @blakeyrat said:

    Why do we care about this meaningless trivia? Go build software.

    Somebody beat me to it. But they left me a piece of shit to work with. :-(



  • Why would getAThingie() return null? So stupid! I want a thingie! If you can't give me a thingie, throw an exception, don't return null or call your stupid method getAThingieOrNull()



  • .NET garbage collection is a raging dumpster fire. It's not automatic, viz. the stupid little boilerplate Dispose() method that Microsoft tries to get everyone to add to their classes. By allowing .NET programmers to forget about their heap objects, what Microsoft has accomplished is to get them to forget about garbage collecting anything (database connections, GDI objects, file locks...) And don't tell me that everyone is just "doing it wrong." If you shove me toward quicksand and I fall in, it doesn't mean I'm clumsy.

    If you ever feel like getting a frontal lobotomy just to be done with life's cares, you might want to just consider reading Microsoft's official advice on "Dispose" (http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx). The effect on your intelligence will be roughly the same. Consider the following:

    "A Dispose method should call the SuppressFinalize method for the object it is disposing. If the object is currently on the finalization queue, SuppressFinalize prevents its Finalize method from being called. Remember that executing a Finalize method is costly to performance. If your Dispose method has already done the work to clean up the object, then it is not necessary for the garbage collector to call the object's Finalize method.

    The code example provided for the GC.KeepAlive method shows how aggressive garbage collection can cause a finalizer to run while a member of the reclaimed object is still executing. It is a good idea to call the KeepAlive method at the end of a lengthy Dispose method."

    A good idea?? No; malloc() and free() were good ideas. What's printed above is just word salad. This little abomination occurs something like 5 paragraphs into Microsoft's "Dispose" advice (which every .NET programmer, of course, must know and love). Who has time for this crap? I'd rather just use malloc(), free(), ReleaseDC(), etc. like a normal, decent person. Sheesh.



  • Ok it's getting old, Bridget. We get it. Ha ha.


  • FoxDev

    @rstinejr said:

    Here's a rare gem of C# found in production code (denatured to protect the guilty):

    Thingie myThingie = yadayada.getAThingie();
    if (myThingie == null)
    {
        // throw exception, Thingie unavailable
        myThingie.Dispose();
        throw new Exception("Thingie unavailable.");
    }
    

    With C# "disposable" instances, you need to make sure to call Dispose, NPE be damned!

    Thank goodness for the helpful comment, however, or I would have been totally at sea.

     

    What it should have been:

    <font face="courier new,courier">using (Thingie myThingie = yadayada.getAThingie())
    {</font>
    <font face="courier new,courier">    if (myThingie == null) throw new Exception("Thingie unavailable.");</font>
    <font face="courier new,courier">    //body
    }</font>

    The compiler automatically generates the Dispose() call, including the check for <font face="courier new,courier">null</font>.

    Clearly the guilty party doesn't know C# very well.



  • You're supposed to do it like this:

    Thingie myThingie = yadayada.getAThingie();
    if (myThingie == null)
    {
        // throw exception, Thingie unavailable
        using (myThingie) {
            myThingie.Dispose();
        }
        throw new Exception("Thingie unavailable.");
    }


  • I'm not sure what it is that you 'get.' Do you agree that .NET garbage collection stinks? I doubt it. I don' t think you are smart enough to realize how stupid that paragraph I posted actually is.



  • @bridget99 said:

    I'm not sure what it is that you 'get.' Do you agree that .NET garbage collection stinks? I doubt it. I don' t think you are smart enough to realize how stupid that paragraph I posted actually is.

    (psst, he was making fun of you)



  • @blakeyrat said:

    Ok it's getting old, Bridget. We get it. Ha ha.
     

    Don't try and discourage him from posting, it's nice that there is someone that makes incompetent schmucks like me feel like geniuses by comparison.



  • @locallunatic said:

    @blakeyrat said:

    Ok it's getting old, Bridget. We get it. Ha ha.
     

    Don't try and discourage him from posting, it's nice that there is someone that makes incompetent schmucks like me feel like geniuses by comparison.

     

    http://forums.thedailywtf.com/forums/t/13917.aspx

     



  • @RaceProUK said:

    What it should have been:

    <FONT face="courier new,courier">using (Thingie myThingie = yadayada.getAThingie())
    {</FONT>
    <FONT face="courier new,courier">    if (myThingie == null) throw new Exception("Thingie unavailable.");</FONT>
    <FONT face="courier new,courier">    //body
    }</FONT>

    The compiler automatically generates the Dispose() call, including the check for <FONT face="courier new,courier">null</FONT>.

    Clearly the guilty party doesn't know C# very well.

    It should be:

    <FONT face="courier new,courier">using (Thingie myThingie = yadayada.getAThingie())
    {</FONT>
    <FONT face="courier new,courier">    //body
    }</FONT>

    Why build a method called "getAThingie" that sometimes doesn't get a Thingie? If the call succeeds, you should have a Thingie; if it doesn't, it should throw an exception. Any other behavior leads to documentation that looks like this:


    Returns: an instance of Thingie... well sometimes. If there is a database connection error, then it will throw an exception, but if the system is out of Thingies, then it will simply return null. Any problem getting a Thingie not listed here will probably throw an exception, but maybe not.




  • I really dont have a clue why people have such trouble with Dispose....other than the syntactic sugar provided by the using statement, there is no fundamental difference between this method and any other virtual method - none.

    If you have "expensive resources" (typically naive) and want a more deterministic means of dealing with them (Dispose does not "release" anything per se) then the convention is to use a method named Dispose and implement the IDisposable (largely so you can identify the class for various reasons - including usability with the using statement).

    That is all...now move along...there is nothing to see here.  <bright flash of light>



  • @bridget99 said:

    A good idea?? No; malloc() and free() were good ideas. What's printed above is just word salad. This little abomination occurs something like 5 paragraphs into Microsoft's "Dispose" advice (which every .NET programmer, of course, must know and love). Who has time for this crap? I'd rather just use malloc(), free(), ReleaseDC(), etc. like a normal, decent person. Sheesh.
     

     

    You only implement IDisposable if your class deals with unmanaged resources. You don't need to dispose all your object; you certainly don't "need" to know how to implement it in order to work in .NET. The basic semantics of how you manage an object that implements IDisposable are pretty much the same as manual memory management; instead of malloc you have new, which presumably allocates the objects unmanaged resources, and then you have .Dispose(), which deallocates them. The things you cite are implementation details of implementing IDisposable, which is not something you will typically need to do.

     

    In fact, it says right in the article for the interface, one of the first sentences of the documentation is "The primary use for this interface is to release unmanaged resources". It doesn't say- or even imply "We here at Microsoft recommend that everybody implement IDisposable on all their objects for no good reason".

     

    Arguably, implementing IDisposable is indeed a pain in the ass; but that's the nature of adding deterministic clean-up to a Garbage Collector. (adding deterministic cleanup to a GC is still easier than adding non-deterministic cleanup to C or C++, though why you would want that is probably a WTF too)

     

     

     

     



  • @Jaime said:

    @RaceProUK said:

    What it should have been:

    <font face="courier new,courier">using (Thingie myThingie = yadayada.getAThingie())
    {</font>
    <font face="courier new,courier">    if (myThingie == null) throw new Exception("Thingie unavailable.");</font>
    <font face="courier new,courier">    //body
    }</font>

    The compiler automatically generates the Dispose() call, including the check for <font face="courier new,courier">null</font>.

    Clearly the guilty party doesn't know C# very well.

    It should be:

    <font face="courier new,courier">using (Thingie myThingie = yadayada.getAThingie())
    {</font>
    <font face="courier new,courier">    //body
    }</font>

    Why build a method called "getAThingie" that sometimes doesn't get a Thingie? If the call succeeds, you should have a Thingie; if it doesn't, it should throw an exception. Any other behavior leads to documentation that looks like this:


    Returns: an instance of Thingie... well sometimes. If there is a database connection error, then it will throw an exception, but if the system is out of Thingies, then it will simply return null. Any problem getting a Thingie not listed here will probably throw an exception, but maybe not.


    If I'm understanding him correctly, he's just saying the compiler automatically generates the null check, not that you should really be writing code that returns null.



  • @BC_Programmer said:

    Arguably, implementing IDisposable is indeed a pain in the ass; but that's the nature of adding deterministic clean-up to a Garbage Collector.

    Or you could have a GC that uses reference counting..



  • @morbiuswilters said:

    @BC_Programmer said:
    Arguably, implementing IDisposable is indeed a pain in the ass; but that's the nature of adding deterministic clean-up to a Garbage Collector.

    Or you could have a GC that uses reference counting..

    For every issue that exists with a "reachability" GC, I can counter with an issue of equivilant significance on a Reference counting GC. There is no "perfect system". Personally (and professionally) I prefer the reachability approach. It works reasonably well for most reasonable situations, and when the need arises, I have never had a problem structuring my design to achieve the required goals because of the GC in .NET. The only thing I often wish for was independent memory management by AppDomain (but that has other impacts also)



  • @morbiuswilters said:

    Or you could have a GC that uses reference counting..

    True. Though most implementations of Reference-counted cleanup are well mocked. (Arguably the only one I can think of, and I'm not even sure if it counts, is COM)

     

    Actually, wait, I just remembered- derp- C++ Smart Pointers use Reference counting, too. But can we call that a Garbage Collector?



  • @BC_Programmer said:

    @morbiuswilters said:

    Or you could have a GC that uses reference counting..

    True. Though most implementations of Reference-counted cleanup are well mocked. (Arguably the only one I can think of, and I'm not even sure if it counts, is COM)

     

    Actually, wait, I just remembered- derp- C++ Smart Pointers use Reference counting, too. But can we call that a Garbage Collector?

    I think so... but that probably means that the official party line is that you cannot.

    To me, automatic variables and RAII are both examples of automatic garbage collection. I continue to struggle to understand why anyone would want to augment these methods with some inelegant, complex, and nondeterministic piece of crap running in another thread. I think it reflects a basic ignorance of CS coupled with a healthy dose of malignant narcissism: I worked hard on this monstrosity and I've got Bill Gates on my side so you WILL use it.



  • @bridget99 said:

    @BC_Programmer said:

    @morbiuswilters said:

    Or you could have a GC that uses reference counting..

    True. Though most implementations of Reference-counted cleanup are well mocked. (Arguably the only one I can think of, and I'm not even sure if it counts, is COM)

    Actually, wait, I just remembered- derp- C++ Smart Pointers use Reference counting, too. But can we call that a Garbage Collector?

    I think so... but that probably means that the official party line is that you cannot.

    To me, automatic variables and RAII are both examples of automatic garbage collection. I continue to struggle to understand why anyone would want to augment these methods with some inelegant, complex, and nondeterministic piece of crap running in another thread. I think it reflects a basic ignorance of CS coupled with a healthy dose of malignant narcissism: I worked hard on this monstrosity and I've got Bill Gates on my side so you WILL use it.

    Technically, if the objects must have something internal (such as the reference count in COM), then it is NOT considered Garbage Collection. If the mechanism is independent of the state and construct of the class, then it is considered Garbage Collection.

    So while RAII based reference counts can be quite useful, they are not considered a "reference counting garbage collector". On the otherhand, if the reference counts are stored externaly, and there is no code directly associated with the object instances (hint: the code must be somewhere) then it would qualify.



  • @TheCPUWizard said:

    @bridget99 said:
    @BC_Programmer said:

    @morbiuswilters said:

    Or you could have a GC that uses reference counting..

    True. Though most implementations of Reference-counted cleanup are well mocked. (Arguably the only one I can think of, and I'm not even sure if it counts, is COM)

    Actually, wait, I just remembered- derp- C++ Smart Pointers use Reference counting, too. But can we call that a Garbage Collector?

    I think so... but that probably means that the official party line is that you cannot.

    To me, automatic variables and RAII are both examples of automatic garbage collection. I continue to struggle to understand why anyone would want to augment these methods with some inelegant, complex, and nondeterministic piece of crap running in another thread. I think it reflects a basic ignorance of CS coupled with a healthy dose of malignant narcissism: I worked hard on this monstrosity and I've got Bill Gates on my side so you WILL use it.

    Technically, if the objects must have something internal (such as the reference count in COM), then it is NOT considered Garbage Collection. If the mechanism is independent of the state and construct of the class, then it is considered Garbage Collection.

    So while RAII based reference counts can be quite useful, they are not considered a "reference counting garbage collector". On the otherhand, if the reference counts are stored externaly, and there is no code directly associated with the object instances (hint: the code must be somewhere) then it would qualify.

    That definition makes sense, i.e. having read your post I am less inclined to categorize RAII as a form of automatic garbage collection. I still think that simple stack variables fit into your definition.



  • @bridget99 said:

    . I still think that simple stack variables fit into your definition.

    There is a shining example of cluelessnes... Garbage Collection only applies when there is an asynchronous relationship between creation and destruction, and some operation must be performed so that the space used by previous objects can be resused, while the live objects are still accessible.

    A stack does not fit this basic requirement as it is strictly a LIFO (Last in First Out), [for 99.99% of implementations] *ALL* of the space on the stack for a given context is allocated in bulk (at the start of a method) and released in bulk (at the end of the method). Thus there is no mixture of live/dead objects that need to be "collected".



  • @TheCPUWizard said:

    There is a shining example of cluelessnes...

    So "garbage collection" traditionally does not refer to stack allocation. Thanks for the information. Do you treat everyone who doesn't immediately know this fact with such disdain? Besides, this is really just a matter of terminology. Stack allocation and RAII are still good alternatives to having an asynchronous garbage collector. They are probably superior in many cases. Do you dispute that? A garbage collector really makes performance uneven in my experience. It makes it difficult to make performance guarantees. Stack allocation and RAII are ways to make guarantees about memory allocation without destroying one's ability to guarantee performance. Do you disagree? Did your naval projects rely on some sort of asynchronous garbage collector? It must have been pretty damn novel to have allowed you to still make hard performance guarantees back in 1979.



  • @bridget99 said:

    @TheCPUWizard said:
    There is a shining example of cluelessnes...

    So "garbage collection" traditionally does not refer to stack allocation. Thanks for the information. Do you treat everyone who doesn't immediately know this fact with such disdain? Besides, this is really just a matter of terminology. Stack allocation and RAII are still good alternatives to having an asynchronous garbage collector. They are probably superior in many cases. Do you dispute that? A garbage collector really makes performance uneven in my experience. It makes it difficult to make performance guarantees. Stack allocation and RAII are ways to make guarantees about memory allocation without destroying one's ability to guarantee performance. Do you disagree? Did your naval projects rely on some sort of asynchronous garbage collector? It must have been pretty damn novel to have allowed you to still make hard performance guarantees back in 1979.

    A few comments...

    1) I do tend to "treat with distain" people who make posts that indicate they have sufficient expertise to make a well qualified statement, then turn out to be "Fakers" (i.e. to not have the basic knowledge to support their position)

    2) "Terminology" is EVERYTHING. Words have specific meanings. If one does not know the meanings and ramifications of a word (along with possible alternatives), then DONT USE THE WORDS!

    3) Different technologies each have their strong points and their limitations. There is no "best" that applies to everything. Stack Allocation and RAII are INFERIOR in many cases as well.

    4) "A garbage collector makes performance uneven" is a complete FALLACY. People who think they have seen it, dont understand what they are seeing. Allocations of memory with .NET are much more deterministic than malloc(), as are the actions that occur when the object goes out of scope. What is being seen is a difference in WHERE "performance is uneven", very few people have done the correct analysis to see if it is more or less [I have].

    5) RAII does NOT make it easier to make performance guarantees. You can never (directly) tell when the reference count is going to hit zero [you dont know who else is going to be holding references].

    6) The Naval systems I created did not. They were embedded systems with nearly everything in ROM.... However, I did design systems in that time frame (1980-1982) which did make use of pretty sophesticated memory management, including asynchronous processing very similar to gargabe collectors, and hard (on the order of 10 clock cycle) performance guarantees permeated the system.



  • @TheCPUWizard said:

    2) "Terminology" is EVERYTHING. Words have specific meanings. If one does not know the meanings and ramifications of a word (along with possible alternatives), then DONT USE THE WORDS!





    This is pretty ironic coming from someone who wrote "distain" and "sophesticated" among many other spelling errors. What does it matter if I called stack unwinding a form of "automatic garbage collection"? This is incorrect in the terminology of the prior art, perhaps, but it doesn't change the fact that stack unwinding is an automatic way to clean up memory allocated at runtime. It's appropriate to contrast stack unwinding (with or without RAII) with so-called "garbage collection." Your post basically admits that e.g.:



    @TheCPUWizard said:

    3) Different technologies each have their strong points and their limitations. There is no "best" that applies to everything. Stack Allocation and RAII are INFERIOR in many cases as well.





    Pretty much anything is superior some of the time. That doesn't justify the status quo, in which most programmers are afraid of having to deallocate memory. I think you know that and you are just being argumentative.



    @TheCPUWizard said:

    4) "A garbage collector makes performance uneven" is a complete FALLACY. People who think they have seen it, dont understand what they are seeing. Allocations of memory with .NET are much more deterministic than malloc(), as are the actions that occur when the object goes out of scope. What is being seen is a difference in WHERE "performance is uneven", very few people have done the correct analysis to see if it is more or less [I have].





    There's no valid comparison between a deallocation strategy that is inherent to basically any executing thread (stack unwinding) and a strategy based on completely proprietary code running in another thread (.NET garbage collection). What you're claiming is that it's no harder to make performance guarantees in a concurrent program than in a single-threaded one. That's just ignorant. In any architecture I can imagine, at some level of measurement, be it 1 millisecond, 1 microsecond, or whatever, a single-threaded, stack-unwinding based solution will work where a solution with a concurrent garbage collector will not. How can you possibly question this?



    @TheCPUWizard said:

    5) RAII does NOT make it easier to make performance guarantees. You can never (directly) tell when the reference count is going to hit zero [you dont know who else is going to be holding references].


    RAII is not reference counting. Maybe the two have been combined in some applications... no doubt you did this while I was still in diapers and the result was glorious beyond my ability to conceive. But RAII can be built atop simple stack unwinding, not reference counting, and if you're going to insult people over questions of detail, you ought to know that. (It's also a pretty big flaw in your attempt to paint RAII as nondeterministic, or as less deterministic than "garbage collection.")



    @TheCPUWizard said:
    6) The Naval systems I created did not. They were embedded systems with nearly everything in ROM.... However, I did design systems in that time frame (1980-1982) which did make use of pretty sophesticated memory management, including asynchronous processing very similar to gargabe collectors, and hard (on the order of 10 clock cycle) performance guarantees permeated the system.

    WTF does being in ROM have to do with memory deallocation? And I have a hard time imagining a concurrent system with 10 cycle performance guarantees on the hardware of 30 years ago. A context switch takes longer than that on most hardware. Did you just lock out interrupts all the time? Didn't the deck officers get mad when the system ignored their input, and spill ketchup on their nice white uniforms? Or were you already retired by then?



  • Getting a bit long to continue the full quote....but...

    a) Yes, I am "sloppy" when it comes to typographical, spelling and grammer errors. However, I strive to be very accurate in the choice of words.

    b) "even" refers to constant time, but not the absoute time. Something that takes 10 seconds +/- 1uS is 3 orders of magnitude more even than something that takes 10mS +/- 1ms. Heap allocation (of non-large objects, which should be considered quite separately) is ALWAY a pointer increment. The allocation time in .NET is a constant. "malloc()" as well as native C++ new, has to search for the "Best fit" block to return. The variance between diferent calls to malloc() can be an order fo magnitude or more. The same is true on the "end of life" side. ". In .NET when an object goes out of scope, NOTHING happens [ ZERO time, quite "even"]. When free() is called, the free store must be seached for blocks which can be collapsed, every major implementation does this within the context of the call, thereby creating a large disparity in exactly how long free takes. The operations on the GC thread have nothing to do with any of this.

    c) RAII and Reference Counting, are more tightly linked than you may think. If "Allocation is Initialization" and the system requires the "Initialization" of reference counting, then this is a priori part of Allocation.

    d) Tight performance guarantees are possible, as I indicated previously. Yes, a context switch for interrupts (except for FIRQ) take longer than the specification, but this really does not matter. If one specifies that "instruction X will execute 2500 clock cycles after instruction Y +/-10 cycles" then all that si required is that the "real" operations under worst case take enough time less than the spcification such that a tight loop can be at the end which synchronizes the timing to meet the specification.


  • Discourse touched me in a no-no place

    @bridget99 said:

    @TheCPUWizard said:

    2) "Terminology" is EVERYTHING. Words have specific meanings. If one does not know the meanings and ramifications of a word (along with possible alternatives), then DONT USE THE WORDS!





    This is pretty ironic coming from someone who wrote "distain" and "sophesticated" among many other spelling errors.
    Nice Straw Man you have there... I assume it was the last prize at your school debating competition?



  • @morbiuswilters said:

    @Jaime said:

    Why build a method called "getAThingie" that sometimes doesn't get a Thingie?...[throw an exception rather than return null on failure]...


    If I'm understanding him correctly, he's just saying the compiler automatically generates the null check, not that you should really be writing code that returns null.

    I was just reporting the code as I found it. There are a lot of people still coding like old-style C where a null return indicates failure. But that's another topic.

    What I was griping about was some conscientious-but-unclear-on-the-concept coder added a line calling "Dispose" that is guaranteed to generate a null pointer exception if it is ever executed, because there is test that the instance var is null that guards the block's entrance.

    It seems that there was not much of a code review before this code got pushed out.



  • @rstinejr said:

    @morbiuswilters said:
    @Jaime said:

    Why build a method called "getAThingie" that sometimes doesn't get a Thingie?...[throw an exception rather than return null on failure]...


    If I'm understanding him correctly, he's just saying the compiler automatically generates the null check, not that you should really be writing code that returns null.

    I was just reporting the code as I found it. There are a lot of people still coding like old-style C where a null return indicates failure. But that's another topic.

    What I was griping about was some conscientious-but-unclear-on-the-concept coder added a line calling "Dispose" that is guaranteed to generate a null pointer exception if it is ever executed, because there is test that the instance var is null that guards the block's entrance.

    It seems that there was not much of a code review before this code got pushed out.

    This is TDWTF, staying on topic is only allowed for a few posts at a time. I saw something shiny and I got distracted; the trolls were getting boring anyways.


  • @Jaime said:

    This is TDWTF, staying on topic is only allowed for a few posts at a time. I saw something shiny and I got distracted; the trolls were getting boring anyways.

    I get much more distracted by these http://www.bing.com/images/search?q=squirrel&id=6173242822E120A563E610E6AD2FCA77E38924E6&FORM=IQFRBA


Log in to reply