yyc12345/YYCCommonplace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc: update documentation

Browse Source 
- use namespace bracket all content in documentation to reduce useless namespace prefix.
- change the argument type of AbstractSetting and CoreManager to yycc_u8string_view instead of const yycc_char8_t*.
- throw exception if given setting name is invalid in ConfigManager, instead of slient fallback.
This commit is contained in:
yyc12345
2024-07-31 14:14:38 +08:00
parent 598aae69ae
commit 1cfbcb3b18
15 changed files with 142 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/exception_helper.dox
View File

@ -1,3 +1,4 @@
namespace YYCC::ExceptionHelper {
/**
\page exception_helper Unhandled Exception Handler
@ -18,13 +19,13 @@ It will be invisible on other platforms.
\subsection exception_helper__usage__code Register Code
In most scenarios, programmer only need call YYCC::ExceptionHelper::Register when program started or module loaded.
And call YYCC::ExceptionHelper::Unregister when program exited or module unloaded.
In most scenarios, programmer only need call #Register when program started or module loaded.
And call #Unregister when program exited or module unloaded.
All details are hidden by these 2 feature.
Programmer do not need worried about the implementation of unhandled exception handler.
Optionally, you can provide a function pointer during calling YYCC::ExceptionHelper::Register as a callback.
The prototype of this function pointer is YYCC::ExceptionHelper::ExceptionCallback.
Optionally, you can provide a function pointer during calling #Register as a callback.
The prototype of this function pointer is #ExceptionCallback.
This callback will be called if any unhandled exception happened.
It provides 2 pathes to log file and core dump file respectively.
So that you can use an explicit way, e.g. \c MessageBox, to tell user exception happened and where are the log files,
@ -77,16 +78,16 @@ YYCC::ExceptionHelper also have a mechanism that make sure the same unhandled ex
For example, you have an executable program A.exe, and 2 dynamic libraries B.dll and C.dll.
A.exe and B.dll use YYCC unhandled exception handler feature but C.dll not.
A.exe will load B.dll and C.dll at runtime.
Although both A.exe and B.dll call YYCC::ExceptionHelper::Register(),
Although both A.exe and B.dll call #Register,
when unhandled exception occurs, there is only one error report output,
which may be generated by A.exe or B.dll accoridng to their order of loading.
The core purpose of this is making sure the program will not output too many error report for the same unhandled exception,
no matter how many modules calling YYCC::ExceptionHelper::Register() are loaded.
no matter how many modules calling #Register are loaded.
Only one error report is enough.
More precisely, we use \c CreateMutexW to create an unique mutex in Windows global scope,
to make sure YYCC::ExceptionHelper::Register() only run once in the same process.
to make sure #Register only run once in the same process.
It is very like the implementation of singleton application.
\subsection exception_helper__notes__recursive_calling Recursive Calling
@ -106,3 +107,4 @@ We want all essential log files has been written before calling it,
so that at least we can visit them on disk or console.
*/
}