Error Handling / Unit Testing

[Zach]

I have to admit, I am woefully uneducated about these concepts although I am aware in general terms of what they are for.
I would like to get some advice on how to create good coding practices to incorporate into my behavior, so that I can start to develop and use my own routines for implementing these functionalities within larger projects.

I have kind of ignored this, but I figure it is a good idea now, while I am still in the (slow) prototyping phase for my Text RPG engine.

Can anyone share some insight in the proper ways to utilize both Error / Exception handling, and Unit testing? In terms of where and how they should be used, where one is appropriate versus the other, if there is any (un)necessary cross-over between them, and how to avoid "over-doing" it?

I admit of the two Unit Testing is someone of a mystery to me, and I'm not sure I understand the reason why it is really needed if you are coding responsibly, but again, that just speaks to my ignorance on the subject.

General ideas or outside links to generic articles are fine, but I am also looking for Purebasic specific examples of implementation, and stuff along those lines. (i.e How do "you" approach it?)

[Demivec]

I admit of the two Unit Testing is someone of a mystery to me, and I'm not sure I understand the reason why it is really needed if you are coding responsibly, but again, that just speaks to my ignorance on the subject.

Unit testing is a way to document the functional requirements of a 'unit' (i.e., procedure, interface, etc.) when written before the unit is created; it is a way to verify the 'unit' meets the functional requirements after it is written; it is useful in regression testing to verify that changes made in code do not cause previously functioning code to fail.

Unit Testing (wikipedia)

Also look at PureBasic's unit testing SDK: PureUnit

[luis]

Surely you will get tons of suggestions about that, I give you one you didn't mention because in my opinion it's the more important since its use keep the program growing without logic errors / false assumptions creeping in. Can give you some of the power of debugging, logging, and unit checking when used in the proper way, with zero cost in the final release. Requires discipline.

Use ASSERTS -> http://www.purebasic.fr/english/viewtop ... 64#p387164

On top of that, then you can put the error handling style you prefer on runtime. Again mine, based on local GOTO usage is certainly not popular -> http://www.purebasic.fr/english/viewtop ... 24#p374524

Code: Select all

Procedure.i test() ; basic usage

 ; some code 

 TRY(retcode > 0)

 ; ... all well

 TRY(handle)

 ; all well

 ProcedureReturn 1 ; success

 CATCH()

 ; cleanup if needed

 ProcedureReturn 0 ; failure

EndProcedure

Code: Select all

Procedure.i test2() ; variant

 ; some code 

 TRY(retcode > 0, #exc_io_error)

 ; ... all well

 TRY(handle, #exc_gdi_error)

 ; all well

 ProcedureReturn 1 ; success

 CATCH()
 
 If EXCEPTION = #exc_io_error
    ; some code
 EndIf

 If EXCEPTION = #exc_gdi_error
    ; some code
 EndIf

 ProcedureReturn 0 ; failure

EndProcedure

the macro

Code: Select all

CompilerIf Defined(#Macro_TRY, #PB_Constant) = 0
#Macro_TRY = 1

Macro TRY (exp, exception_code = 0) 
 Global EXCEPTION
 
 If Not (exp)
    EXCEPTION = exception_code 
    Goto label_catch_exception
 EndIf
EndMacro

Macro CATCH()
 label_catch_exception:
EndMacro

CompilerEndIf

[Zach]

Interesting, I hope others will contribute some other examples. That does look a little intimidating, I admit.
luis, what is the CPU cost of using your method?

I was kind of thinking of something similar, but using IF/Else or some such. Like the way OpenWindow() commands are called in the Help examples.

[luis]

luis, what is the CPU cost of using your method?

The ASSERT is zero at release time. It's not there. At debug time depends on the expression you evaluate in the ASSERT obviously. When failed shows a blocking window.
The fake TRY/CATCH is an IF with a jump that normally it's not executed. You can't have an error checking simpler than that.

I was kind of thinking of something similar, but using IF/Else or some such.

It's the same thing. Well, not. It's similar. Using the macro is a lot easier to spot and follow the flow when looking back at the code. An IF can be there for various reason, a TRY() only for one. But the key aspect is the hidden GOTO instead of a deep structured mess.

BTW: thanks again to Fred for implementing local labels.