Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I see a lot of code written where an exception is thrown if a parameter is not in the right form, or whatever. Basically “throw new …”.
What is the benefit of this? The exception can be avoided by checking the parameters (Eg if null, write message back to webpage/winform). Why is this approach not used when an exception is expensive?
Thanks
A few points are worth making here:
First, your supposition that exceptions are expensive is generally untrue – exceptions are, well … exceptional. They shouldn’t be occurring often enough to have any meaningful effect on program performance. And if you are seeing enough exceptions that performance is a problem then you have bigger fish to fry.
Second, a well written class, function or module program should be able to detect and handle invalid input somewhat gracefully. It helps the maintainers and debuggers of the code locate the problems as close to their introduction as possible. If arguments are not checked, they can often result in a failure much later in the code – far removed from the actual error. Debugging such problems can be very painful.
Third, you assume that all code is aware of the context in which it is executed. A method may be deep in a framework or library and have no knowledge of whether it is running in a web application, console app, NT service, etc. Besides, it’a terrible practice to pepper logic to display information about invalid arguments throughout the body of your code – that responsibility should be centralized and controlled – otherwise you UI could easily become a mess of errors interspersed with actual presentation content.
Finally, exceptions allow a program to sometimes handle and recover from a problem rather than exposing it to the user. Don’t diminish this capability by directly displaying errors immediately when they occur. Now, granted, most often invalid arguments are a symptom of a programming defect (rather than an environmental or configuration issue) – and so in most cases they can’t be handled. But, then again, sometimes they can be handled.