Worse than outsourcing...
-
ToddHileHoffer wrote:
I have not used try catch blocks in any of my web applications outside of the global file in about three years.
You can do it that way, but it doesn't make it the right way. It may work for you, but in general it's not a great way - for instance, your web application uses multiple web services and one of them has a problem. What exception do you get back? You can't use reflection here because you've got to deal with SoapExceptions and they aren't handled as normal exceptions. The best place to work with these exceptions is in the web service, not propagated back up through the call stack Similarly - if you provide a web service to external applications, what should you do if there's an exception? Let that propagate up to a client or deal with it yourself.
Deja View - the feeling that you've seen this post before.
The web services I write use the same error handler in a global file. If an error occurs I get all the info about the service. The ones I have written for outside vendors have never thrown an exception. They aren't that complex. If I was calling an outside vendors web service, I might use try catch blocks...
I didn't get any requirements for the signature
-
I agree! Using one catchall for errors is just lazy programming. Exceptions are designed to known expcetion at a local level where the design should know more about the condition and be able to make the call if it is a valid error and we need to abort or it is something we can handle at that level. In addition to localizing of the error block, it localizing your error reporting back to the user. Instead of throwing up some generic error message about the hampsters running off the wheels, you can actually give your users a more informative error.
Rocky <>< Recent Blog Post: Netflix Gets Starz!
If there is a certain type of exception that you can trap and continue with the code than sure it makes sense to write try catch blocks. I have never come across that situation. Every time my code has thrown an error, it is a bug that needs to be fixed. It isn't about laziness either. Having a global error handler makes sure that all the bugs are accounted for and logged in the same place. I have worked in Environments where ever program had custom error handling and exceptions were just killed in try catch blocks and nothing was ever done with them. Using my global error handler, if an error occurs in a .net web page, I'll get an email with the line of code that caused the error. That's not laziness, it is good design and it makes life easy. Granted I have only worked in small corporations with < 1000 users. I'm not writing code for Amazon.com.
-
Pete O'Hanlon wrote:
Please don't make blanket generalisations about exception handling
Exception handling is for girls.
-
ToddHileHoffer wrote:
I have an error handler I've been tweaking for years now. It uses reflection goodness and a whole lot more. If I get an exception it emails me the line number of the code that caused the problem the stack trace + all the session / viewstate / cookies / page info etc. If the error is a sql problem I get the sql text that caused it.
Could I persuade you to share this with us? :-D
I didn't write all of this, it has been around for years. Also, I leave the debug set to true in the web.config. It is a performance hit, but that's not an issue in my environment. Our server is fast and we don't have that many users. using System; using System.Collections.Generic; using System.Text; using System.Net.Mail; using System.Web; using System.Collections.Specialized; using System.Configuration; using System.Collections; using System.Reflection; public class ErrorHandler { #region Declarations const String heading = @"
"; const String td = @""; private HttpApplication application = null; private Exception exception = null; private string messageBody = string.Empty; private MailPriority mailPriority = MailPriority.Normal; private string subject = "Application Error"; private bool isWebApp = false; #endregion #region Configuration //********************************** // You must have the following in the web.config or ap.config // "autoDebugTo" // "autoDebugFrom" // "smtpHost" //********************************** private List toEmail { get { List objReturn = new List(); if (ConfigurationManager.AppSettings["autoDebugTo"].ToString().Contains(";")) { foreach (string x in ConfigurationManager.AppSettings["autoDebugTo"].ToString().Split(";".ToCharArray())) objReturn.Add(new MailAddress(x)); } else objReturn.Add(new MailAddress(ConfigurationManager.AppSettings["autoDebugTo"].ToString())); return objReturn; } } private MailAddress fromEmail { get { return new MailAddress(ConfigurationManager.AppSettings["autoDebugFrom"].ToString()); } } private string smtpHost { get { return ConfigurationManager.AppSettings["smtpHost"].ToString(); } } #endregion #region cTor public ErrorHandler(Exce
-
are you sure you understand the web properly? :omg:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
Of course I understand it. It's just that I don't work for an IT company. Web Services don't play a role in most of the Intranet applications I work on.
I didn't get any requirements for the signature
-
Of course I understand it. It's just that I don't work for an IT company. Web Services don't play a role in most of the Intranet applications I work on.
I didn't get any requirements for the signature
so then would you say that making blanket statements about "the web" and what is and isn't a good idea for web programming might not be your forte? i mean given that you say you're not working in a "web" environment as such just curious as your advice is just plain misguided for the web at large :|
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
Pete O'Hanlon wrote:
Please don't make blanket generalisations about exception handling
Exception handling is for girls.
god doesn't use
try {
......
} catch (e){
...
}he uses
try {
.....
} chuck (norris){
...
}and it gets handled :rolleyes:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
so then would you say that making blanket statements about "the web" and what is and isn't a good idea for web programming might not be your forte? i mean given that you say you're not working in a "web" environment as such just curious as your advice is just plain misguided for the web at large :|
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
Why is using a global error handler misguided exactly? If you can trap and error, do something and continue on with your code then use a try catch block. But that's rare isn't it? Otherwise, you don't need a try catch block. Just use the global asax. What is wrong with that?
I didn't get any requirements for the signature
-
Why is using a global error handler misguided exactly? If you can trap and error, do something and continue on with your code then use a try catch block. But that's rare isn't it? Otherwise, you don't need a try catch block. Just use the global asax. What is wrong with that?
I didn't get any requirements for the signature
well with exceptions you should try to handle them where they happen so you can *try* to do something meaningful or at least give a meaningful error message checking user input with client-side validation is absolutely essential in the web at large i was just making the point that you seem to be in a particular environment that isn't really "the web" as such but that your blanket sounding statements appear to be describing what you think web programming should be about no offence meant at all was just musing :)
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
I think you make it worst than it is. Just try to divide the work between the two of you so that you do not step over your toes all time. Maybe you do one set of pages, he does another set of pages, given that you agree on the fundamentals such as database schemas or whatever everything should work fine. Also it might help to determine who the lead developer is in case a decision needs to be taken on a topic you two disagree.
Don´t worry, in a couple of months he will be promoted, so be kind to your future boss! :laugh:
-
I have met a couple Russians who were actually good at programming... BTW, using try catch blocks in a web application is so pointless. Just use the global asax and call your error handler...
I didn't get any requirements for the signature
ToddHileHoffer wrote:
I have met a couple Russians who were actually good at programming...
I'm not imposing anything. :) Nationality has nothing to do with it.
ToddHileHoffer wrote:
using try catch blocks in a web application is so pointless.
Not if you can actually handle the exception. It's no different than in desktop, console and server applications.
-
I think you make it worst than it is. Just try to divide the work between the two of you so that you do not step over your toes all time. Maybe you do one set of pages, he does another set of pages, given that you agree on the fundamentals such as database schemas or whatever everything should work fine. Also it might help to determine who the lead developer is in case a decision needs to be taken on a topic you two disagree.
VentsyV wrote:
Just try to divide the work between the two of you so that you do not step over your toes all time. Maybe you do one set of pages, he does another set of pages
We try to do that, I had to let some of the steam to go off yesterday because he touched MY classes and introduced a catch all construct and a not thread safe call in it, so I felt like my class was raped. :P
-
I didn't write all of this, it has been around for years. Also, I leave the debug set to true in the web.config. It is a performance hit, but that's not an issue in my environment. Our server is fast and we don't have that many users. using System; using System.Collections.Generic; using System.Text; using System.Net.Mail; using System.Web; using System.Collections.Specialized; using System.Configuration; using System.Collections; using System.Reflection; public class ErrorHandler { #region Declarations const String heading = @"
"; const String td = @""; private HttpApplication application = null; private Exception exception = null; private string messageBody = string.Empty; private MailPriority mailPriority = MailPriority.Normal; private string subject = "Application Error"; private bool isWebApp = false; #endregion #region Configuration //********************************** // You must have the following in the web.config or ap.config // "autoDebugTo" // "autoDebugFrom" // "smtpHost" //********************************** private List toEmail { get { List objReturn = new List(); if (ConfigurationManager.AppSettings["autoDebugTo"].ToString().Contains(";")) { foreach (string x in ConfigurationManager.AppSettings["autoDebugTo"].ToString().Split(";".ToCharArray())) objReturn.Add(new MailAddress(x)); } else objReturn.Add(new MailAddress(ConfigurationManager.AppSettings["autoDebugTo"].ToString())); return objReturn; } } private MailAddress fromEmail { get { return new MailAddress(ConfigurationManager.AppSettings["autoDebugFrom"].ToString()); } } private string smtpHost { get { return ConfigurationManager.AppSettings["smtpHost"].ToString(); } } #endregion #region cTor public ErrorHandler(Exce