Question

I've noticed that FogBugz isn't throwing trappable errors when executing queries via the plugin's database api.

For example, If I build a query with invalid syntax and then open it with code like this.

try {
    DataSet dsBugQuery= queryBugs.GetDataSet()
}
catch {
    //this will never be called, even if the query errors.
}

The catch block never gets fired. The FB reports the error in the UI, but it is the raw error information directly from the FB code.

This is making it tricky for me to troubleshoot errors in plugins for my users. Is there some way that I can catch these errors and handle them gracefully?

Update:
Here is an example stack trace for an error in my plugin that eluded my try/catch block. In this case it was a WikiPage query.

System.ArgumentException: Invalid syntax: expected boolean expression, found 'is'

Server stack trace: 
   at FogCreek.FogBugz.Database.CSqlParser.ParseBoolTerm(CSqlTokenList tokens)
   at FogCreek.FogBugz.Database.CSqlParser.ParseBoolExpression(CSqlTokenList tokens)
   at FogCreek.FogBugz.Database.CSqlValidator.AssertValid(String s, String sType)
   at FogCreek.FogBugz.Database.CSqlValidator.AssertValidWhereList(String s)
   at FogCreek.FogBugz.Database.CWhereQuery.AddWhere(String sSqlWhere)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at FogCreek.FogBugz.Database.CWhereQuery.AddWhere(String sSqlWhere)
   at WikiArticleIndex.WikiArticleIndex.getTocHTML(Int32 ixWiki, Int32 ixWikiPageExclude)
   at WikiArticleIndex.WikiArticleIndexBlockManager.RenderWikiBlock(WikiBlock block, RenderingMode mode)
   at System.Text.RegularExpressions.RegexReplacement.Replace(MatchEvaluator evaluator, Regex regex, String input, Int32 count, Int32 startat)
   at System.Text.RegularExpressions.Regex.Replace(String input, MatchEvaluator evaluator)
   at FogCreek.Plugins.Wiki.Util.RegexRepo.Replace(WikiBlockRegexType type, String sInput, MatchEvaluator meMatchHandler, RegexOptions roOptions, List`1 rgsPluginTypes)
   at FogCreek.Plugins.Wiki.Util.RegexRepo.Replace(WikiBlockRegexType type, String sInput, MatchEvaluator meMatchHandler, List`1 rgsPluginTypes)
   at WikiArticleIndex.WikiArticleIndexBlockManager.WikiPageDisplayView(CWikiPage oPage, String sContents)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [1]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at FogCreek.FogBugz.Plugins.Interfaces.IPluginWikiPageDisplay.WikiPageDisplayView(CWikiPage page, String sContents)
   at FogCreek.FogBugz.CWikiPage.get_BodyForView() in c:\code\dogfood\build\FB8.4.76H\fogbugz\src-Website\CWikiPage.was:line 155

Answer 1

Could you give us a few more details? What is queryBugs querying? What exception is being thrown? What does the stack trace look like?

My suspicion is that the problem is a combination of

1. The actual underlying query is being executing in the FogBugz AppDomain (i.e., not your plugin's AppDomain b/c query objects are all MarshalByRef)
2. The exception being thrown is not MarshalByRef, and is therefore failing to make its way into your plugin's AppDomain...and so can't be caught there.

If that's the case, we can wrap the exception in something that is MarshalByRef or throw an equivalent exception of our own (if wrapping a non-MarshalByRef exception doesn't work).