I am in the process of creating a large set of BO's based on the CSLA framework. I am relatively new to .Net as well so please forgive me if I should know the answer to this question already. Essentially I want to know how you recommend handling unhandled exceptions (unexpected program errors) in a class library. I have seen examples of how to do this in a forms application but I want to keep my errors in my class library if possible considering that we will have many UIs plugging into these same BO's (also EIF seems like overkill for us).
Here is what I envision but where to put it I am not sure:
Select Case TypeOf(Exception)
Case CslaDataException
Case InvalidOperatorException
ETC......
Here we can do like in our current C++ and VB apps where we send detailed error information to a web service where they can be tracked by user/machine, and other details.
Thanks in advance for your assistance,
Rob
In most cases, UI should handle and report the error to user for further action.
I think you should use structured exception to handle the runtime error. This applies to both UI and BO library. For example,
try {
...
}
catch (CslaDataException) {
...
}
catch (InvalidOperatorException) {
...
}
catch (Exception) {
...
}
Regards,
William
William,
Thanks for the response. But I want to be able to completely handle the unhandled exception within my BO and pass this on to the UI in the manner I see best. The Try/Catch is fine with anticipated errors but with a large complex application dealing with thousands if not millions of data records there is always a possibility for unanticipated errors. Quoting an MSDN article:
"In this installment of the .NET column I am going to present a handful of tips for dealing with unexpected errors. While it is common practice to catch exceptions to deal with expected failure cases, it is also common for managed applications to encounter errors for which the application is completely unprepared. In an ideal world you will establish clear policies for how your application discovers and responds to unhandled exceptions, reduced security permissions, and other related edge-cases, but in practice these are often overlooked."
What I would like is some kind of global unhandled error listener within the BO so that I could uniformly respond to among other errors data errors which could occur many places within the BOs.
Any thoughts or assistance from anyone in the group is greatly appreciated.
Rob
William..
I hav seen ur valuable comments regarding the Exception handling in both BO and UI.
But i am asking, can i catch an exception in a EditableRootListBase object....I am trying with it..
But I cant handle the exception through an EditableRootListBase..
Any help in this problem..
Regards
Devi..
The rule with exceptions is to only catch them if you can do something about the exception, or something useful with the exception. Examples include:
In most applications it is totally impractical to catch and resolve all exceptions in the business layer. As you say, there are unexpected exceptions that you simply can't deal with.
You are far better off allowing those exceptions to flow up to the UI so you can use the exception detail to notify the user of the issue and take appropriate steps at that level. Remember, the UI is responsible for guiding the user through the application - and some exceptions may require closing a window, opening a new window or whatever.
If you don't allow the exception to flow up to the UI, you'll be stuck writing Win32 API style (C-style) code where, after every interaction with a business object, your UI must include code to check some error status property to see if something bad happened.
The whole point of exceptions is to get away from that coding model. Obviously it can be done, but to some large degree you'll be fighting the whole philosophy of .NET.
Rocky,
Thank you for your reply. This is a learning process for me.
What got me started thinking on this were errors I generated when the database connection did not succeed. I thought it might be nice for a central error catching to catch this error and then throw it on to the UI or log it in the Event Log in the case of a non-UI (ie - Service).
After your answer in the case of a UI my plan now is to surround the DataPortal_Fetch call (in the factory procedure) with a TryCatch which in turn throws a custom exception which the UI's error handling will respond by bringing up the data settings for the BOs. Does this sound reasonable to you?
Thanks Again,
Rob
Yes, one valid way to add value is to catch an exception and
rethrow it as a more explicit or meaningful exception (with the original as the
innerexception). This is what CSLA does with the dataportalexception for
example.
Rocky
From: culprit
[mailto:cslanet@lhotka.net]
Sent: Wednesday, June 06, 2007 9:52 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Unhandled Exception
Rocky,
Thank you for your reply. This is a learning process for me.
What got me started thinking on this were errors I generated when the
database connection did not succeed. I thought it might be nice for a central
error catching to catch this error and then throw it on to the UI or log it in
the Event Log in the case of a non-UI (ie - Service).
After your answer in the case of a UI my plan now is to surround the
DataPortal_Fetch call (in the factory procedure) with a TryCatch which in
turn throws a custom exception which the UI's error handling will respond by
bringing up the data settings for the BOs. Does this sound reasonable to you?
Thanks Again,
Rob
Howdy,
I am looking over the error handling procedures for a Medical Record application that we are writing.
I have an example of a situation and would like to know what the experts out there would suggest.
Say I call a simple factory method with a patient id. That then calls the dataportal_fetch.
My dataportal_fetch method does its sql query and starts to go through the datareader.
If the datareader has no records then I would say that you had an invalid patient ID and throw a PatientBusinesException(“Invalid PatientId”) exception. This exception then gets wrapped by 2 dataportal exceptions through the framework.
Now, the UI caller of the factory method gets a dataportal exception. How is the UI to know that it is an invalid patientID(that it could handle vs a sqlexception that should go up the chain) that started this exception chain without having to write some extra code inside each try catch block that catches a dataportalexception and looks inside to see what really happened?
It would seem to me that if I initially threw a custom business exception then that should be on the outer most layer so you can use simple, multiple catch blocks in place of some custom case statement.
I have thought of catching the dataportal exception inside the shared function and re-throwing the inner exception, but it starts the stack trace over and you lose the initial data.
Any guidance would be appreciated
Thank you,
Keith
Your custom exception can’t be on top of the stack without
losing the data in the DataPortalException…
In VB this is kind of a non-issue thanks to the When clause:
Try
‘…
Catch ex As DataPortalException When TypeOf ex.BusinessException
Is PatientBusinessException
‘…
Catch ex As DataPortalException When TypeOf ex.BusinessException
Is SomeOtherException
‘…
Catch ex As Exception
‘…
End Catch
But in C# it is rather a pain.
So here’s an alternative for the factory method:
public static Patient GetPatient(…)
{
try
{
DataPortal.Fetch<Patient>(…);
}
catch (DataPortalException ex)
{
Exception newEx =
Activator.CreateInstance(typeof(ex.BusinessException.GetType()),
new object[] { ex.BusinessException.Message, ex});
throw newEx;
}
}
To be honest, I just threw this together off the top of my head,
so it might not work. But it should work – the only oddity you’ll see is that
your business exception appears twice in the exception stack. The stack will be
something like this:
PatientBusinessException
DataPortalException
PatientBusinessException
SqlException
The stack trace should remain intact because the inner exception
of the new exception is the DataPortalException, and it contains the full stack
trace.
Rocky
From: ksirmons
[mailto:cslanet@lhotka.net]
Sent: Thursday, August 02, 2007 3:46 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Unhandled Exception
Howdy,
I am looking over the error handling
procedures for a Medical Record application that we are writing.
I have an example of a situation and
would like to know what the experts out there would suggest.
Say I call a simple factory method
with a patient id. That then calls the dataportal_fetch.
My dataportal_fetch method does its
sql query and starts to go through the datareader.
If the datareader has no records
then I would say that you had an invalid patient ID and throw a
PatientBusinesException(“Invalid PatientIdâ€) exception. This exception then gets wrapped by
2 dataportal exceptions through the framework.
Now, the UI caller of the factory
method gets a dataportal exception. How is the UI to know that it is an
invalid patientID(that it could handle vs a sqlexception that should go up the
chain) that started this exception chain without having to write some extra
code inside each try catch block that catches a dataportalexception and looks
inside to see what really happened?
It would seem to me that if I initially
threw a custom business exception then that should be on the outer most layer
so you can use simple, multiple catch blocks in place of some custom case
statement.
I have thought of catching the
dataportal exception inside the shared function and re-throwing the inner
exception, but it starts the stack trace over and you lose the initial data.
Any guidance would be appreciated
Thank you,
Keith
Rocky,
Thank you. This is exactly what I am looking for.
We are coding in VB and I will try the When clause, but do you know if your c# code would port to VB?
Thank you,
Keith
Sure, that same code would work in VB – pretty much just
drop the semi-colons J
But the When clause is often an easier and quite elegant
solution if you are in VB.
Rocky
From: ksirmons
[mailto:cslanet@lhotka.net]
Sent: Thursday, August 02, 2007 4:45 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: Unhandled Exception
Rocky,
Thank you. This is exactly what I am looking for.
We are coding in VB and I will try the When clause, but do you know if your
c# code would port to VB?
Thank you,
Keith
Copyright (c) Marimer LLC