You are assuming that the stack trace is generated, which for many anticipated exceptions it is not. For anticipated exceptions, you would simply catch it and adjust. For example, the code is attempting to use a connection to the database to execute a query, but the connection timed out before the query could be transmitted. To handle this error, one would simply need to reconnect and retry and the problem is solved without any fuss. I would rather have an exception here because I'd rather not see every call in the stack between the beginning of the query call and the attempt to use the connection have to return and check an error code.
That leaves unanticipated exceptions, for which the engineer will likely want the error output to help them track down what happened. In the case of unanticipated exceptions, yes you have a much slower method of logging, but you get a lot of useful information that helps the engineer track down the problem quickly. For example a query to the database is malformed which generates an exception which likely will end the execution of at least that part of the application. Having the exception take 1000x longer to handle in this case is trivial compared to the fact that it happened at all, and well worth the cost for the information about the error that it provides (a stack trace, versus nothing but an error condition).
I spent a lot of time dealing with virtual hosting and SSL and only the latest patched versions of IE7 & IE8 support embedding the domain name in the SSL request.
Mozilla does support this, but seems to attempt a standard SSL request first (not sure which version I was testing with now - was the latest at the time). Webkit based browsers seemed to be the only ones that properly send the domain upon every SSL connection attempt. SSL is designed to allow but not require a header for the domain which is necessary if the server is virtual hosting using a separate SSL certificate for each domain hosted. I believe it is possible to combine the SSL certificates for each domain hosted and send the combined cert to the client regardless of which domain is requested, however this requires a much more expensive SSL cert. For those of us wanting free certs this really isn't an option.
As far as the authors argument that SSL certs are expensive, they are not. You can get a perfectly good and perfectly free cert from StartCom, and possibly other vendors as well. The true reason SSL is not often used is certainly due to server side processing cost. Caching is not generally relevant since most of the expensive resources are images which can be downloaded using a non-SSL connection within the SSL encrypted page without worrying about man in the middle attacks.
What is truly sad is that Java does not yet support this domain SSL header yet - meaning if you are using the language to write your web server, you have to wrapper each SSL connection to capture the header yourself. Common Snorkle, what are you waiting for?
Slashdot Mirror
the plant where Homer Simpson is working?
You are assuming that the stack trace is generated, which for many anticipated exceptions it is not. For anticipated exceptions, you would simply catch it and adjust. For example, the code is attempting to use a connection to the database to execute a query, but the connection timed out before the query could be transmitted. To handle this error, one would simply need to reconnect and retry and the problem is solved without any fuss. I would rather have an exception here because I'd rather not see every call in the stack between the beginning of the query call and the attempt to use the connection have to return and check an error code.
That leaves unanticipated exceptions, for which the engineer will likely want the error output to help them track down what happened. In the case of unanticipated exceptions, yes you have a much slower method of logging, but you get a lot of useful information that helps the engineer track down the problem quickly. For example a query to the database is malformed which generates an exception which likely will end the execution of at least that part of the application. Having the exception take 1000x longer to handle in this case is trivial compared to the fact that it happened at all, and well worth the cost for the information about the error that it provides (a stack trace, versus nothing but an error condition).
I spent a lot of time dealing with virtual hosting and SSL and only the latest patched versions of IE7 & IE8 support embedding the domain name in the SSL request. Mozilla does support this, but seems to attempt a standard SSL request first (not sure which version I was testing with now - was the latest at the time). Webkit based browsers seemed to be the only ones that properly send the domain upon every SSL connection attempt. SSL is designed to allow but not require a header for the domain which is necessary if the server is virtual hosting using a separate SSL certificate for each domain hosted. I believe it is possible to combine the SSL certificates for each domain hosted and send the combined cert to the client regardless of which domain is requested, however this requires a much more expensive SSL cert. For those of us wanting free certs this really isn't an option. As far as the authors argument that SSL certs are expensive, they are not. You can get a perfectly good and perfectly free cert from StartCom, and possibly other vendors as well. The true reason SSL is not often used is certainly due to server side processing cost. Caching is not generally relevant since most of the expensive resources are images which can be downloaded using a non-SSL connection within the SSL encrypted page without worrying about man in the middle attacks. What is truly sad is that Java does not yet support this domain SSL header yet - meaning if you are using the language to write your web server, you have to wrapper each SSL connection to capture the header yourself. Common Snorkle, what are you waiting for?