B
Bill McCormick
Linda Liu[MSFT] wrote:
[snip]
Again, I'm having a serious problem with this if your saying that
LinqToSql cannot process varchar(1) data fields.
Your understanding of the subject matter specific to deferred loading
notwithstanding, I think you are missing my point: that is that the
exception SHOULD be able to be caught at the user (form) level. If in
fact it can only be caught at the application level by looking for
Unhandled exceptions, I think this is not proper design.
Anyway, this is how I've handled it for now, except I believe it is more
proper to shutdown the application at this point. When handling
exceptions that have bubbled to the top like this, you have to consider
that the application may have been left in some improper state. Leaving
the application running for all unhandled exceptions should be avoided.
Bill
[snip]
parent record in the JobOrderTable. Due to the improper data type of the
DspPltSide field in the Dsp table, the FormatException occurs.
Again, I'm having a serious problem with this if your saying that
LinqToSql cannot process varchar(1) data fields.
The above behavior of LINQ to SQL is called deferred loading, which means
when you query for an object, you actually retrieve only the object you
requested. The related objects are not automatically fetched at the same
time. You cannot see the fact that the related objects are not already
loaded, because an attempt to access them produces a request that retrieves
them.
Your understanding of the subject matter specific to deferred loading
notwithstanding, I think you are missing my point: that is that the
exception SHOULD be able to be caught at the user (form) level. If in
fact it can only be caught at the application level by looking for
Unhandled exceptions, I think this is not proper design.
Since the data retrieving happens in the main UI thread, we can capture
this FormatException by handling the
Application.DispatcherUnhandledException event. Open the App.xaml file and
add the following attribute to subscribe the DispatcherUnhandledException:
<Application x:Class="ScAggScale.App"
DispatcherUnhandledException="Application_DispatcherUnhandledException"
....>
In the App.xaml.cs file, add the following event handler:
public partial class App:Application
{
private void Application_DispatcherUnhandledException(object sender,
System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
MesssageBox.Show("Unhandled Exception:" + e.Exception.Message);
e.Handled = true;
}
}
Anyway, this is how I've handled it for now, except I believe it is more
proper to shutdown the application at this point. When handling
exceptions that have bubbled to the top like this, you have to consider
that the application may have been left in some improper state. Leaving
the application running for all unhandled exceptions should be avoided.
Bill