@Ninefingers answers the question quite well; I just want to add a few details.

Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ciphertext attacks) and also avoids any trouble to confidentiality from the MAC (since the MAC operates on the encrypted text, it cannot reveal anything about the plaintext, regardless of its quality). Note that the padding oracle attacks, which have been applied in the field to ASP.NET, are chosen ciphertext attacks.

Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the initialization vector, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algorithm; otherwise, the attacker could change either, inducing a plaintext alteration which would be undetected by the MAC. To prove their point, Ferguson and Schneier describe an attack over an instance of IPsec in which the encrypt-then-MAC was not done properly.

So while encrypt-then-MAC is theoretically better, it is also somewhat harder to get right.

Some additional details to the accepted answer.

Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ciphertext attacks) and also avoids any trouble to confidentiality from the MAC (since the MAC operates on the encrypted text, it cannot reveal anything about the plaintext, regardless of its quality). Note that the padding oracle attacks, which have been applied in the field to ASP.NET, are chosen ciphertext attacks.

Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the initialization vector, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algorithm; otherwise, the attacker could change either, inducing a plaintext alteration which would be undetected by the MAC. To prove their point, Ferguson and Schneier describe an attack over an instance of IPsec in which the encrypt-then-MAC was not done properly.

So while encrypt-then-MAC is theoretically better, it is also somewhat harder to get right.

@Ninefingers answers the question quite well; I just want to add a few details.

Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ciphertext attacks) and also avoids any trouble to confidentiality from the MAC (since the MAC operates on the encrypted text, it cannot reveal anything about the plaintext, regardless of its quality). Note that the padding oracle attacks, which have been applied in the field to ASP.NET, are chosen ciphertext attacks.

Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the IV, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algorithm; otherwise, the attacker could change either, inducing a plaintext alteration which would be undetected by the MAC. To prove their point, Ferguson and Schneier describe an attack over an instance of IPsec in which the encrypt-then-MAC was not done properly.

So while encrypt-then-MAC is theoretically better, it is also somewhat harder to get right.

@Ninefingers answers the question quite well; I just want to add a few details.

Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ciphertext attacks) and also avoids any trouble to confidentiality from the MAC (since the MAC operates on the encrypted text, it cannot reveal anything about the plaintext, regardless of its quality). Note that the padding oracle attacks, which have been applied in the field to ASP.NET, are chosen ciphertext attacks.

Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the initialization vector, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algorithm; otherwise, the attacker could change either, inducing a plaintext alteration which would be undetected by the MAC. To prove their point, Ferguson and Schneier describe an attack over an instance of IPsec in which the encrypt-then-MAC was not done properly.

So while encrypt-then-MAC is theoretically better, it is also somewhat harder to get right.