bind() is massively used in many JavaScript projects, which is not surprising, given the magic it offers. A recent scan through the source code I work on indicated more than 2300 of them. The large scale of usage raise my concerns about what impact this massive usage might bring - especially on performance and memory footprint. Clearly, I was not alone: Patrick Mueller wrote this great article specifically about the matter: bind() considered harmful.

Something we should always keep in mind is that bind() returns a new function, as Patrick mentioned, which is basically separated from the original one (except that they share the implementation). Instead of the garbage it might create (frankly I think it's unlikely that someone would write code to bind() functions in a loop), I'd mention that you should be careful when distinguishing both copies and which one you should use, especially when it comes to add/remove event listeners. Given the easy-going nature of JavaScript, you will only realize you used the wrong one at run time.

An interesting fact about bind() is that it could do a bit more than just binding an object to "this", it also accepts a list of arguments which you could pass to the function you call bind() on. The interesting part is how few this feature has been used - out of 2300+ uses of bind() in our code, less than 50 of them were accompanied with optional arguments. And you could easily see why - just by looking at the example on MDN:

function list() {
 return Array.prototype.slice.call(arguments);
 }
 
 var list1 = list(1, 2, 3); // [1, 2, 3]
 
 // Create a function with a preset leading argument
 var leadingThirtysevenList = list.bind(undefined, 37); // this could easily creates problem if bound function is not properly named
 
 var list2 = leadingThirtysevenList(); // [37]
 var list3 = leadingThirtysevenList(1, 2, 3); // [37, 1, 2, 3]

If you failed to maintain a good naming convention on the bound functions, it could soon become error-prone. The problem is that the clients of this bound function might not have knowledge on what arguments it already travels with. In fact, many developers just assign the bound function back to the original function itself, since they really don't needs an object that only holds the implementation. Just as Patrick mentioned in his article - this could easily gets in the way of debugging. 

Is var that = this a better solution?

Obviously, we can't get rid of bind(), regardless it's actual harmful or not. JavaScript utilize callback (or eventhandler, whichever way you call it) far more than a lot of other languages. And due to the dynamic binding of JavaScript, you probably can't live without it. But there is a simple (and elegant, in my opinion) alternative though - you could use the pattern of defining a local variable that saves off the mighty "this" object in the scope. And naturally it will be available to any callbacks you defined via closure. "that" seems to be a popular choice of name for this matter, I've seen other names such as "context" or "scope" used in this matter as well.

In theory this should be better than using bind(), assuming your sole purpose is to provide access to this in the callback (as mentioned above, this takes up most part of bind()'s usage). Since it performs a simple variable assignment, and potentially bypassed some logic that bind() might have (eg. analyzing arguments). I should mention this is just an educated guess from me, but doing a simple test on jsPerf seems to support it: bind-vs-that.

Your thoughts? Feel free to let me know by leaving a comment!

In fact, despite that many similarities between Java and C# as managed languages, how to re-throw exceptions makes a profound difference between them.

As you might remember, in Java, re-throwing a exception can be easily done by:

try{
 ... // code that may throw exception
 } catch (Exception e) {
 throw e;
 }

The only line you need to look at is "throw e;", which is really not very interesting in the context of Java, but works entirely differently in C# if you write the same line:

try
 { 
 ... // code that may throw exception 
 } 
 catch (Exception e) 
 { 
 throw e; 
 }

The difference is: In Java, when you do "throw e;", you are essentially re-throwing that exception "as-is", which means the original stack trace - the most important thing here - is preserved. While in C# (or VB and other .NET languages I assume), the same syntax will cause the stack trace to be overridden by the line that re-throw the exception, which is very unlikely what you want.

So, to answer the question of "How to properly re-throw exceptions in C#", you have two options:

1. Instead of "throw e;" just use "throw;", which works like a charm.

2. Create a new exception with the information of old one, such as "new newExp ( "Exception happened when I do bla-bla-bla", e )". This is usually more suitable for the case when you want to add some additional information about the error.

Hope this will help some other new C#ers as well! :)

One more thing, if you've been wondering what to do with an exception (especially those unchecked ones), here's a blogpost on "Coding Horror" by Jeff Atwood which contains a handy guideline for exception handling: https://www.codinghorror.com/blog/2004/07/rethrowing-exceptions.html 

* But note that author made a mistake about the difference I talked above and he clarified later in the comment. Don't be tricked :P  

This is caused by, as far as I see it, that Fiddler sometimes fails to unregister itself as the system proxy upon on quitting. In that case you will be redirecting all your HTTP traffic to a proxy that doesn't exist, and thus gives you the error shown above.

Easy way to fix this, is to reluanch Fiddler application which will act as system proxy again (make sure you set the option in "Fiddler Options" - "WinINET Connetions"). Close the application gracefully and it should fix the connetion path for you.

Or, you could manually clear the proxy settings by going to Internet Options, select "LAN setting" in "Connections" tab, and uncheck the option of "Use a proxy server for your LAN". (In which you should see a proxy like 127.0.0.1:8888, which is the default listening port for Fiddler.)

At some points I was almost certian that this is a hardware problem, as I tried re-installing repeatedly and the problem resisted. However, the actual problem was caused by connecting my machine to two monitors. The root cause was clear: the driver for the graphic card got flushed during the re-installation of WIndows, and thus it won't know how to support dual-display. Apparently Windows 8 doesn't handle this problem gracefully but rather dumping a black screen.

So, if you run into the same problem, it's most likely because you computer was connected to some external device that it doesn't suppport(at that sepcial point). You should disconnect the devices while leaving only one monitor. It should solve the problem for you.           

static byte[] ConvertToBytes(string inputString)
 {
 byte[] outputBytes = new byte[inputString.Length * sizeof(char)];
 Buffer.BlockCopy(inputString.ToCharArray(), 0, outputBytes, 0, outputBytes.Length);
 return outputBytes;
 }

In some other cases when you want to concatenate two byte arrays, while you don't want to bother doing the convention between strings. Here's a easy way of doing it, which also employs Buffer.BlockCopy. Note that it appends the Byte[] arrayB to the end of Byte[] arrayA:

static byte[] AppendTwoByteArrays(byte[] arrayA, byte[] arrayB)
 {
 byte[] outputBytes = new byte[arrayA.Length + arrayB.Length];
 Buffer.BlockCopy(arrayA, 0, outputBytes, 0, arrayA.Length);
 Buffer.BlockCopy(arrayB, 0, outputBytes, arrayA.Length, arrayB.Length);
 return outputBytes;
 }

Suppose you have a XML file which looks like following:

<?xml version="1.0" encoding="utf-8" ?>
 <list>
 <title>FeaturedMovies</title>
 <movie>
 <name>Grey</name>
 </movie>
 <movie>
 <name>Haywire</name>
 </movie>
 <movie>
 <name>Harry Potter</name>
 </movie>
 </list>

Ideally after parsing, we should have a list of objects which simply contains a string filed, the "name". There are no attributes involved in this file, just for the purpose of demonstrating the simplest case. Here's the code that will properly decode it:

 using System;
 using System.Xml;
 using System.Collections.Generic;

 class Movie
 {
 public string name;
 public string searchToken;
 public string guid;
 }
 static void Main(string[] args)
 {
 XmlTextReader textReader = new XmlTextReader("C:\\MoviesList.xml");
 
 List<Movie> movieList = new List<Movie>();
 
 while (textReader.Read())
 {
 Movie movie = new Movie();
 
 if (textReader.MoveToContent() == XmlNodeType.Element && textReader.Name == "name")
 movie.name = textReader.ReadElementString();
 if (textReader.MoveToContent() == XmlNodeType.Element && textReader.Name == "searchToken")
 movie.searchToken = textReader.ReadElementString();
 
 if (!String.IsNullOrEmpty(movie.name))
 movieList.Add(movie);
 }
 }
 

You might notice that none of the movies in the XML actually have a "searchToken", while this will still work fine. But since we want the "name" to be mandatory, we do check for it before adding that into the list.

Hope this will save you sometime! :)