locked
Best Practices for Exception handling and LINQ RRS feed

  • Question

  • Can anyone point me to some best practices for exception handling when using LINQ. We're struggling to come up with a architectural policy that neatly encapsulates the specific issues that using LINQ raises, in particular the deferred execution means that any exceptions that are thrown are only thrown deep in the UI unless we enumerate in our business logic.
    Monday, March 31, 2008 10:11 AM

Answers

  •  

    Bernard,

     

    Since this thread has been sat for a while, I thought that I'd get onto it, and see if there was any way that I could help you out.

     

    I know of LINQ but am definitely not an expert in it, however if perhaps you explain the particular problems you're facing in a little more detail, I can offer some ideas or guidance on an approach that you might take?

     

    I'm not really understanding how LINQ would force an exception up to the UI?  Surely that would be down to how you architect your solution?  What I mean is that you'd still have your layered architecture, and appropriately handle data or in fact business exceptions regarding LINQ in the approapriate layer.  Obviously if there are some binding problems, or some other UI issues that are specific to presentation, and everything that could be checked was checked, then the exception would have to be handled in the presenter (assuming you're using an MVP, or MVVM or similar pattern)

     

    Perhaps if this doesn't help, you could further detail your problems?

     

    Martin Platt.

    Thursday, April 3, 2008 10:22 PM

All replies

  •  

    Bernard,

     

    Since this thread has been sat for a while, I thought that I'd get onto it, and see if there was any way that I could help you out.

     

    I know of LINQ but am definitely not an expert in it, however if perhaps you explain the particular problems you're facing in a little more detail, I can offer some ideas or guidance on an approach that you might take?

     

    I'm not really understanding how LINQ would force an exception up to the UI?  Surely that would be down to how you architect your solution?  What I mean is that you'd still have your layered architecture, and appropriately handle data or in fact business exceptions regarding LINQ in the approapriate layer.  Obviously if there are some binding problems, or some other UI issues that are specific to presentation, and everything that could be checked was checked, then the exception would have to be handled in the presenter (assuming you're using an MVP, or MVVM or similar pattern)

     

    Perhaps if this doesn't help, you could further detail your problems?

     

    Martin Platt.

    Thursday, April 3, 2008 10:22 PM
  • Hi Bernard,

    without going deep on LINQ concepts I suggest you to keep a consistent policy for exception handling across the whole application (or at least, inside the boundaries under your control)

     

    There are some resources and guidance about that. You may figure out how to reapply that better to the case of LINQ. Eventually you may open this thread on C#, VB.NET or any other coding forum where you may get a more detailed information based on your programming language

     

     

    Tuesday, April 22, 2008 8:41 PM