ThinkGeo.com    |     Documentation    |     Premium Support

Fail earlier?

#1

I have a question about your exception model. I'm fairly new to your software so this might be more important to me than to most. There have been times when I've done something wrong (usually it's when I've refactored something), but rather than the ThinkGeo software telling what I've done wrong, the error happens after all my code has executed and gets caught in mscorlib. Certainly, the error has been mine, but it seems that the errors I'm causing would be fairly simple for the map software to check rather than just letting it propogate. And then by the time it gets to mscorlib, I get some fairly meaningless error like "The supplied key isn't in the dictionary." or "Input was not in the correct format.".


The times that I've noticed this that I can remember include:


Having an incorrect column name on the feature (same as not having the column, I guess)


Not realizing that a string I used was going to be converted to a number. (I can't recall exactly what caused that one, but my co-worker and I each individually raised it.)


I put a 0 in for an int as the final value in a constructor (sorry I don't remember where that was and I must have refactored that code away). It turned out that the range started at 1, but again I got some weird windows error.


I think there was at least one other case, but I don't recall it. In any case, I'm wondering why you don't fail earlier? I'm trying to make sure I add unit tests to my code when I run into this, but from the point of view of learning, it would be rather nice to get an error telling me that the column I referenced doesn't exist. As I mentioned, it's usually when I refactor something and I have a habit of thinking my refactored code should work exactly the same as it did before. :-D


Thank you!


Kimberly


 



#2

Kimberly, 
  
 Thanks very much for your suggestions, that’s really good. 
  
 In fact, almost all the public methods (public and protected) have the parameters checking at the entry point. If you have chance to see our source code, you will find the parameter checking all over the place.  From what you said, seems our checking is still not enough though. For example, if input 0 to a 1-based integer, it should throw an exception, we might overlook that. Thanks for pointing that out and we will keep on improving the exception system in the future.  
  
 Thanks again! 
  
 Ben

#3

Thank you for the response Ben. I imagine it would be pretty difficult to come up with all possible errors we're going to generate.


Kimberly


 



#4

That’s difficult to cover all the places but your feedback will always help us make it better. Thanks for pointing this out, Kimberly. 
  
 Ben

#5

If we can tell you of checking that we would like to see performed...  I'm writing custom layers and features sources.   I've had some experiences in getting layers added to a map w/o a feature source.    That creates a stack trace of 1347 levels (maybe a slight exageration), and ends with a null reference exception error :)



#6

Ted, 
  
 1347 levels,  that’s something :).  We will gradually and surely add all the checking we can think of and I hope in the future release, you will not meet any issues like that. 
  
 By the way, can you let me know how to recreate the 1347 stack trace issue? I think it must use recursive or something but I’m not sure where it is.  
  
 Thanks, 
  
 Ben