Hello,
It's been reported multiple times, both by myself and by other customers, that your components sometimes catches exceptions thrown outside their boundaries and swallows / occults them unexpectedly:
Q490642 - XtraBars - BeforeShowMenu (when using a DocumentManager instance)
Q448229 - XtraGrid - RowUpdated event (long conversation on exception swallowing here)
Q21612 - (same as above)
Q487716 - XtraGrid - CustomRowFilter event
Q471004 - XtraPrinting - Exception swallowing for custom ICommandHandler
Q431436 - DXGrid - ColumnsPopulated event (I couldn't personnally check this one)
Q492778 - MVC GridView - BindToLinq
T171197 - XtraGrid with AutoFilterRow and Apply method
T172377 - XPServerCollectionSource when using ServerExceptionThrownAction.Rethrow (!)
As you (should) know, this kind of practice can seriously compromise an application's quality and reliability. As per .NET standards, a developer expects uncaught exceptions to bubble up the stack, to a point where it's logged for debugging purposes right before the app is closed to protect the end user's data. This coding pattern is very common and goes on par with Microsoft best practices.
Therefore, by hiding exceptions away, your components breaks up the framework's normal exception handling structure and introduces a significant risk for applications to be left running in a corrupted state.
Now, I don't want to go back to fighting with you guys to fix things up. You (most sadly) made it pretty clear that you won't.
However, I believe that each KNOWN scenarios like these should AT THE VERY LEAST be documented, both in a standalone list and as a subsection within the concerned members documentation. The workarounds that were proposed in the above tickets should be there too.
By doing this, you'd allow your customers to be aware of the situation and to take appropriate measures for exceptions thrown within these invokers (or nested further down the stack) to be properly dealt with.
This simple update in the documentation won't break any existing code (duh!), so there's no reason for you not to do it. Obviously it's not as good as fixing things up, but it's still far, FAR better than letting your customers find out in unpleasant ways that their application isn't working properly.
Please DevExpress, do the right thing here.
UPDATES:
2013-08-12 - Added Q492778
2014-11-11 - Added T171197
2014-11-13 - Added T172377 and links