Hello all,

I am currently in the process of designing the Business Logic for an application and am unsure of exactly how I should implement exceptions.

So my understanding of exceptions is that they are for "exceptional circumstances" that may occur during the program flow. The problem I have is what to do in the case when your code actually finds the issue through logic/validation/testing. I think an example might make it a little clearer as to what I am trying to say...

So my main experience is with developing user-interface designs. Now say I had the code that could result in the classic divide by zero error. In a user interface I would do a test before this. If the data passed was going to result in a divide by zero error I would use conditional logic to skip the divide, prompt the user again and continue on when they enter a correct value:

if (b > 0)
c = a/b
else
Prompt the user again etc etc...

I'd never think of using an exception in this case because to me this isn't an unexpected occurrence and can be coded for. Another example would be a file not found case. I wouldn't send a file_not_found exception, I'd test whether the file exists, and if it didn't, report that to the user and wait for what they wanted to do...again no exceptions.

I'm a bit thrown by what to do with the Business logic though. Take the divide by zero example. I can test for this in the business logic but what action would I take? I can't prompt the user for the data again because that has no place in the business logic layer. I could have the DivideByZero method return with a status reporting the failure but this results in either a lot of extra status parameters, or using the return value to return the status when it should really be used to return the result. That leaves me with having the Business Logic layer throw an exception to the UI layer. For some reason this doesn't feel right to me as I've always thought of exceptions as being used for something unforeseen happening...a divide by zero can be tested for though?

So am I still following good design principles if I have my business logic throwing divide_by_zero, file_not_found etc exceptions...or is there another way I should be doing this? I know the UI should do most of the validation, but if I want the Business Layer to be reusable and modular it needs to have no reliance on UI testing.

Would be great to hear from anyone who has some insight into this.

---

Bhavin.

You have no choice, you cannot handle the error condition. In fact, you should throw your own exceptions when you see the UI layer sending you bad data. Much better than a divide by zero exception, the user would have a hard time guessing what particular data entry item caused it. Be sure to provide the tools the UI layer needs to avoid these exceptions.

---

Hans Passant.

You have no choice, you cannot handle the error condition. In fact, you should throw your own exceptions when you see the UI layer sending you bad data. Much better than a divide by zero exception, the user would have a hard time guessing what particular data entry item caused it. Be sure to provide the tools the UI layer needs to avoid these exceptions.

---

Hans Passant.