Suggestion for Exception Handling in Custom Styles and other places

[Greg]

Hi,

I've noticed that when I have an exception in one of my custom styles, inside the DrawCore override, that the only stack that gets bubbled up looks like this:

System.NullReferenceException: Object reference not set to an instance of an object. 

   at ThinkGeo.MapSuite.WpfDesktopEdition.Tile.<>c__DisplayClass2.<drawexception>b__0() 

   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) 

   at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object  source, Delegate method, Object args, Int32 numArgs, Delegate  catchHandler)</drawexception>

I would like to see more information around the cause of the actual problem in the exception.  I suspect that ThinkGeo code is catching the exception and rethrowing a new exception, without settiing the original exception as the InnerException property of the new exception.

I have gone through all of my DrawCore overrides and added a try/catch with a log.error and a rethrow, as a way to work around this problem.  But I think it would be cleaner if ThinkGeo gave me more information and I suspect that other customers would like their exceptions to be more descriptive so they realize that their exception is caused by their code and not ThinkGeo code!

I have noticed this type of problem in other areas as well... but I cannot remember the specific cases.

Here are the Microsoft Guidelines for Wrapping Exceptions : msdn.microsoft.com/en-us/library/ms229049.aspx

They state.... "Do specify the inner exception when wrapping exceptions.  This  allows tools to display the underlying details of the problem and can  aid in debugging code. ...."

Thanks,

Greg

[Ryan1]

We see this a lot too…  not for custom styles but just for random crashes that get logged from our users machines.  It’d definitely be nice if we could get more information…

[Gary2]

Hello Greg and Ryan, 
  
 Thanks for the post. Yes we are not the first time met this exception problem, but almost different user has different error reason, so it’s hard to say what’s the root cause just by this error message. 
  
 We will consider sort out all kind of exception and re-check the exception handle logic, thanks for the suggestion. 
  
 And if you can recreate this problem with a sample, I think I can debug and reslove it for you. 
  
 Regards, 
  
 Gary

[Greg]

I'm a bit confused by the ThinkGeo response on this, and I want to keep pushing on this because I find it rather serious.

You state:  "but almost different user has different error reason, so it's hard to say what's the root cause just by this error message."

Well... by following the Microsoft guidelines, different users would have an easier time determine the root cause of their exceptions if ThinkGeo didn't "Eat" the exception.  Different users need to know if there was an inner exception.  I fail to see how the quoted statement above can be used as a possible reason for ThinkGeo's departure from Microsoft guidelines on this in any way... it is actually a reason to follow the guidelines.  Am I missing something here?  I apoligize if I am, but my opinion is that the way ThinkGeo handles exceptions is a serious problem.  Let me tell you why:

1) It takes me and my team more time to fix exceptions.  In our application, we log all crashes to a log file.  When a customer reports a crash, we get the log file.  When we get a crash in our map code, all we see is a vague description because ThinkGeo is not properly wrapping exceptions.  And, many of these exceptions are difficult to reproduce because we don't have all the steps.  If ThinkGeo properly wrapped the exception as an inner exception, it would take us much less time to fix the bug.  This is a CRITICAL issue for us, as we do have customers we want to make happy by providing excellent customer support.   Quickly fixing their bugs is CRITICAL.  One day of down-time for our customers can cost them hundreds of thousands of dollars.  The way ThinkGeo is Eating exceptions and not wrapping exceptions is huge impediment towards us being able to provide top quality customer support.

2) There are a number of places in our map code where we have random try/catch blocks because the perception is that ThinkGeo just randomly crashes.  In most of these cases where we did get a crash, we've eventually determined that the exception was caused by something bad we were doing in the code.  We determined this by turning on the CLR Exceptions off the Debug->Exceptions dialog in Visual Studio.  However,  at one point, the perception throughout our management chain was that ThinkGeo was not the go-forward direction for us due to seemingly random crashes.  We've even researched other alternative products and were extremely close to switching to different vendors.  It would be unfortuneate to lose customers due to a perception of bad quality that is driven by something that is easy to address in the code.  This is a silly question, but .....   Is there a business reason you have for making poor quality in your customer's code appear to be a problem with ThinkGeo code?

In my opinion, I've layed out two pretty strong business arguments for changing how you handle exceptions.   Perhaps there is something in your architecture / design that would preclude you from following the guidelines, and if there is, please communicate that with me.  Our mapping component is a critical part of our overall solution, and we need for it to be as solid as possible.

-Greg

 

 

 

[David]

Greg, 
  
   To clear up the confusion on this we will be very clear.  We try to never eat exceptions and many times we get complaints from users about this.  I am not saying it is not there at ll but that is not the standard we have.  When we catch errors and then bubble them up we simply throw them again.  I am not sure on your particular issue and I think that is the response from Gary saying that he is not sure the source.  Also in the context of the tile and multi threading drawing sometimes the stack is very terse.  What we can do is to search the entire core and main products for all traces of exceptions and make sure that we are including the inner exceptions if applicable.  
  
 David

[Greg]

Thank you for the response David.

-Greg

[Gary2]

Hello Greg, 
  
 You are welcome, please feel free to let us know your questions. 
  
 Regards, 
  
 Gary

[Piotr_Czabanski]

Example: put the null into feature.ColumnValues[“XX”]=null and then map.Refresh() - I suppose you can point the feature by its Id but all what we get is null exception with no additional information.

[Ethan]

Hi Piotr_Czabanski,

It looks I don’t understand your reply about this problem, does it a share or you also have question about it?

Regards,

Ethan