GDIPlusX: Error handling suggestions

Topics: General
Aug 10, 2006 at 8:43 PM
I would like to get some feedback on the error handling for the GDIPlusX classes. Currently all the methods are wrapped in a TRY/CATCH and we THROW the exception of any error that occurs during that method.

This works well for unhandled exceptions but what should we do for these known errors:

- A non-OK status from any of the Gdip* functions: Currently these are being held in the LastStatus property. This idea came from the C++ version of the GdiPlus classes, but the .NET version of the classes will actually THROW an exception. So, currently the calling code has no idea the method failed unless you check the value of the GetLastStatus( ) method. I'm thinking we should change this to throw an exception also.

- Invalid parameters: Currently most of these are being ignored. We have CASE statements checking the data types of the parameters (to simulate overloads) but there is usually nothing in the OTHERWISE clause to deal with any invalid parameters.

- Invalid data types assigned to properties: For some of the critical properties, like X and Y on the xfcPoint class. We have code similar to this in the ASSIGN method:
This.X = INT(tnValue)
This does 2 things, it forces the property to be an integer and will THROW an exception if the user passes an non-numeric value. We may want to do something similar for all read/write property assignments.

- Values assigned to ReadOnly properties: There are many properties in this library that are ReadOnly. Most of these properties require ACCESS code to get the true property value (using some GdipGet... function call). Originally, I had generated the classes to throw a 1740:"read-only property" error in the ASSIGN method of these properties. Because there were so many, it added about 200KB to the overall size of the library. I was concerned that the library was getting too large and because it doesn't really matter what was ASSIGNED to the property, I decided to just ignore the ASSIGN. Now I'm wondering if developers would rather get an error than have the value ASSIGNment ignored.

- Any other ideas....

Aug 11, 2006 at 9:51 PM
Hey Bo,

I'm still not sure about how the errors need to be treated, but I've "invited" my brazilian colleagues to download and test the classes.

At this moment, when a bug occurs, there's no way for them to report. Note that the majority of them don't have any experience with the classes, so they'll have diddficulties to understand the errors and to report them.

For now, a simple messagebox, showing the most common informations, like program, method, line etc would help a lot.

While we are still in Alpha versions, maybe we could create a "Errors" folder, and the error handling routine could save a simple TXT file containing the information we need to do the fixes.

Just some ideas...
Aug 11, 2006 at 9:53 PM
... Continued

This way, people would just send to us those TXT's
Oct 13, 2006 at 4:24 AM
Hello Friends,
excuse for my bad English. I hope you understand me.
But my suggestion is the following:
- we be verified the parameters they are properly with your types.
- we would change the names of all the parameters for the following nomenclature:
- Integer - cd_name
- Character - ds_name
- test - tst_name
- We would verify executing a function of the type: validation_param(parametro,name)
- through a function of a PRG. We would have the following:

function validationparam (param1,_param2)
type = left(param1,2)
case _type='cd'
return = iif(type('param1')<>'N','integer','ok')
case _type='ds'
return = iif(type('param1')<>'C','string','ok')
if _return<>'ok'
messagebox("The parameter '"alltrim( _param2)"' is invalid. Use "_return" value",'Error')
return .F.
return .T.

In the moment I don't have better suggestion.

Rafael Lippert