Last post Jan 14, 2011 10:34 AM by rscott54
Jan 11, 2011 05:42 PM|rscott54|LINK
I have a web form for a user to update their user information. I have an ObjectDataSource configured to use the Update method in my BLL. If the user changes their email address in the web form, the BLL Update code checks to make sure the email address
is not already in use. If it is in use, I want to cancel the update and notify the user.
I was going to raise an ApplicationException in the BLL and catch it in the web form code-behind, then present a message to the user. But from what I read, this is bad practice: http://blogs.msdn.com/b/kcwalina/archive/2005/03/16/396787.aspx
What is the best practice in this situation?
Jan 11, 2011 07:16 PM|AceCorban|LINK
best practice is the one that works for your needs.
That said, I prefer to register client scripts to notify the user.
Jan 12, 2011 10:07 AM|rscott54|LINK
must be a common task, but the articles I have read so far don't give any examples how to do this - they just advise not to use ApplicationException. If someone has come across an article with a good approach, a link to it would be appreciated.
Jan 12, 2011 11:44 AM|AceCorban|LINK
I'm assuming you mean Business Logic Layer? Meaning you want to ensure a strict delineation between your Business Logic and your Presentation. While this is a good architectural mindset to follow, there really is no direct way to do something in your presentation
conditionally based on server logic without some level of connection. I suppose another option would be to have the messages in divs and have your BLL set the appropriate .Visible property.
Jan 12, 2011 12:33 PM|rscott54|LINK
Yes, I'm referring to the Business Logic Layer. I've been doing some more research, and I gather that in my instance I would want to raise an exception in my BLL if the update fails, but also provide a method for checking in advance if the email address
is already in use. Then in the UI, I should check for the email's existence before doing the update in order to avoid throwing the exception. (the Tester-Doer pattern in the article I mentioned in the first post). The reason for this advice appears to be
I am still puzzled by the advice not to use ApplicationException. I looked through the list of exception types (http://mikevallotton.wordpress.com/2009/07/08/net-exceptions-all-of-them), and I don't really see one that is more suitable.
Jan 12, 2011 12:36 PM|AceCorban|LINK
It is an interesting approach to be sure. If you have a good, solid discipline of catching exceptions, it might be a good method for you. I have heard that try/catch blocks can be a little resource-intensive, but I honestly haven't seen solid research
to suggest one way or the other.
Jan 12, 2011 04:21 PM|atconway|LINK
What is the best practice in this situation?
Honestly, unless you are a purist on the topic of exceptions, allowing them to raise and bubble up from any lower layer (1...n) is perfectly acceptable for many situations. Sometimes adding your own framework for wrapping exceptions that Inherits from System.Exception
is sought to add additional information useful to debugging and tracing. In many cases where exceptions can not be explicitly handled, they are often bubbled up to the topmost layer for logging, supressing possibly, and then landing the client softly when
something bad happens.
Be careful of blog posts that state, "Don't just use System.Exception..." They purists have decent viewpoints, but at the end of the day you need to handle exceptions properly for a few main reasons:
1. To handle and resolve at runtime where possible to let the app heal and continue processing.
2. To help with support, debugging, tracing after the fact for the support/development team
3. To prevent clients from seeing any hard exceptions in their browser.
Do whatever you need to satisfy these requirments and any others that may be pertinent to your application and process.
Hope this helps!
Jan 13, 2011 11:26 AM|rscott54|LINK
As I have thought more about it, basically I am trying to validate data here. I think I have to do the validation in the BLL. If the data is not valid, I can't save it to the database. I was thinking of throwing an ApplicationException in the BLL, then
catching it in the UI and notifying the user of the invalid data. But if I do that, I would be routinely throwing exeptions which may be a performance problem?
It seems that the alternative is to code the validations in the UI as well as the BLL and avoid throwing exceptions. This would be more code and would potentially result in more hits on the database (once in the UI and again in the BLL).
What would you do?
Jan 13, 2011 02:29 PM|doyleits|LINK
There is nothing wrong with creating your own exception type (inheriting from the Exception class) that has your own custom properties or behavior. For example, you could throw a custom UserNameNotValidException, that has properties for the username used,
timestamp information, etc.
If your application is designed such that you cannot return a true/false value based on the success of the operation, it is a solid design to use custom exceptions and/or exception handling.
Another reason to use custom exceptions is that you can catch each kind, and display a message accordingly.
// attempt to create user
catch (UserNameNotValidException ex1)
// display message for username not valid
catch (PasswordNotValidException ex2)
// display message for invalid password
catch (Exception ex)
// handle all other exceptions
Jan 14, 2011 10:34 AM|rscott54|LINK
Thanks to everyone for their input. I will try doyleits' approach and see how it goes.