Chaos Project

Featured Projects => Advanced RPG Creator => ARC Welder => Topic started by: Ryex on October 01, 2011, 08:34:23 pm

Title: Logging Errors and exceptional cases in ARCed
Post by: Ryex on October 01, 2011, 08:34:23 pm
The Kernel module is now equipped with a "Log" function that writes messages to a log file.

Kernel.Log(message=None, prefix="[Kernel]", error=False)


it generates a time stamp and uses the provided prefix to create a message

so a call like this

Kernel.Log("message goes here", "[Prefix]")


will create this message

MON 24 SET 2011 15:32:19 [GMT] [Prefix] message goes here


it also has a additional option argument that will attach a trace back of the latest error to be raised to the message

so a call like this

Kernel.Log("message goes here", "[Prefix]", True)


will create a message like this

MON 24 SET 2011 15:32:19 [GMT] [Prefix] message goes here [Error] Traceback


all the arguments are optional and if Message is left as None error will be set to true.

so a call
Kernel.Log()


will generate the following message
MON 24 SET 2011 15:32:19 [GMT] [Kernel] [Error] Traceback


so, when working on the editor:
Title: Re: Logging Errors and exceptional cases in ARCed
Post by: Blizzard on October 02, 2011, 03:35:58 pm
Quote from: Ryex on October 01, 2011, 08:34:23 pm
messages are written to ARCed.log in the program folder


Bad idea. Better write here:

Code: Windows XP
%ALLUSERSPROFILE%\Application Data\ARCed\


Code: Windows Vista / Windows 7
%ALLUSERSPROFILE%\ARCed\


Get the proper environment variables by interfacing the kernel function GetEnvironmentW(). I can give you the wrapper code for that if you want.
Title: Re: Logging Errors and exceptional cases in ARCed
Post by: Ryex on October 02, 2011, 04:40:31 pm
Ok, I'll change that. any particular reason it's a bad Idea to save it in the local directory?
Title: Re: Logging Errors and exceptional cases in ARCed
Post by: Blizzard on October 02, 2011, 04:46:25 pm
Premission problems. Windows won't allow you to write in Program Files or some similar folder because of that. All applications should put their stuff in "C:\Documents and Settings\Application Data" on XP and "C:\ProgramData" on 7 (where the environment variable ALLUSERSPROFILE comes into play). You will notice that pretty much all half-decent applications will put their stuff in there.
Title: Re: Logging Errors and exceptional cases in ARCed
Post by: Ryex on October 02, 2011, 04:51:39 pm
*face palm* of course. That makes perfect sense.
Title: Re: Logging Errors and exceptional cases in ARCed
Post by: Ryex on October 04, 2011, 02:06:16 am
ok, the folder name will be retreved with
wx.StandardPaths.Get().GetConfigDir()
it returns the proper OS dependent path
Title: Re: Logging Errors and exceptional cases in ARCed
Post by: Ryex on October 23, 2011, 11:53:33 pm
Ok. I implemented Kernel.Protect.
basicly you encase a function object like so
 Kernel.protect(func_obj)
and it will catch any raised errors and log them with Kernel.Log and Kernel.Log will in turn inform the user of the error with a message box IF the wx.app has been created.

so a normal function call looks like this
self.func_obj(*args)

a protected function call would look like this
Kernel.Protect(self.func_obj)(*args)


it is particularly important when a function is called by a wxpython event as once an error has been raised and passes into a C++ wxpthon portion of the call stack it can't be caught anymore. wxpython will catch the error print it to stdout and try to continue as if nothing happened if the error isn't caught before this point.

so when binding a function to a wxpython event if the function could reasonably throw an error wrap the function with Kernel.Protect like so
self.Bind(wx.EVT_X, Kernel.Protect(self.OnEventX))

instead of the normal Bind call
self.Bind(wx.EVT_X, self.OnEventX) 
Title: Re: Logging Errors and exceptional cases in ARCed
Post by: Ryex on August 31, 2014, 10:57:21 pm
ok, so this might seem a bit stupid, reviving this topic for such a seemingly redundant question but I was looking at the code to day and I saw I was using ALLUSERSPROFILE, why not use APPDATA?
most applications I see now days use APPDATA (C:\Users\<NAME>\AppData\Roaming)