<commit_before>Title: A common fatal error and assert fail handler

Description:

These two common handler is in order to reduce the redundancy code writing
for fatal and assert handler for error case testing. They can be used both
in kernel and userspace, and are also SMP safe.


Why doing this
==============

When writing error testing case (or we call it negative test case), we might
have to write self-defined k_sys_fatal_handler or post_assert_handler to deal
with the errors we caught, in order to make test going on. This mean much
identical code would be written. So we try to make it as a common part and
let other test case or app can reuse it.

And when error happened, it sometimes need a special action to make our testing
program back to normal, such as release some resource hold before error
happened. This is why we add a hook on it, in order to achieve that goal.


How to use it in you app
========================

(a) Usage for dealing with fatal error:

Step1: Add CONFIG_ZTEST_FATAL_HOOK=y into prj.conf

Step2: Include <ztest_fatal_hook.h> in C source file.

Step3: (optional) Define a hook function call ztest_post_fatal_error_hook().

Step4: Call ztest_set_fault_valid(true) before where your target function
       call.


(b) Usage for dealing with assert fail:

Step1: Add CONFIG_ZTEST_ASSERT_HOOK=y into prj.conf

Step2: Include <ztest_assert_hook.h> in your C code.

Step3: (optional) Define a hook function call ztest_post_assert_fail_hook().

Step4: call ztest_set_assert_valid(true) before where your target function
       call.


You can choose to use one or both of them, depneds on your need.
If you use none of them, you can still defined your own fatal or assert handler
as usual.


Test example in this test set
=============================

This test verifies if the common fatal error and assert fail handler works.
If the expected error got caught, the test case pass.

test_catch_assert_fail
  - To call a function then giving the condition to trigger the assert fail,
    then catch it by the assert handler.

test_catch_fatal_error
  - start a thread to test trigger a null address then catch fatal error.
  - start a thread to test trigger a illegal instruction then catch fatal
    error.
  - start a thread to test trigger a divide zero error then catch fatal error.
  - start a thread to call k_oops() then catch fatal error.
  - start a thread to call k_panel() then catch fatal error.

test_catch_assert_in_isr
  - start a thread to enter ISR context by calling irq_offload(), then trigger
    an assert fail then catch it.

test_catch_z_oops
  - Pass illegal address by syscall, then inside the syscall handler, the
    Z_OOPS macro will trigger a fatal error then got caught.



Limitation of this usage
========================

Trigger an fatal error in ISR context, that will cause problem due to
the interrupt stack is already abnormal when we want to continue other
test case, we do not recover it so far.


---------------------------------------------------------------------------

Sample Output:<commit_msg>tests: error_hook: documentation and style fixes in README<commit_after>Title: A common fatal error and assert fail handler

Description:

These two common handlers are developed in order to reduce the redundancy
code writing for fatal and assert handler for error case testing. They can
be used both in kernel and userspace, and they are also SMP safe.


Why doing this
==============

When writing error testing case (or we call it negative test case), we might
have to write self-defined k_sys_fatal_handler or post_assert_handler to deal
with the errors we caught, in order to make the test continue. This means much
identical code would be written. So we try to move the error handler definition
into a common part and let other test suites or applications reuse it, instead
of defining their own.

And when error happens, we sometimes need a special action to make our testing
program return back to normal, such as releasing some resource hold before the
error happened. This is why we add a hook on it, in order to achieve that goal.


How to use it in you app
========================

(a) Usage for dealing with fatal error:

Step1: Add CONFIG_ZTEST_FATAL_HOOK=y into prj.conf

Step2: Include <ztest_fatal_hook.h> in C source file.

Step3: (optional) Define a hook function call ztest_post_fatal_error_hook().

Step4: Call ztest_set_fault_valid(true) before where your target function
       call.


(b) Usage for dealing with assert fail:

Step1: Add CONFIG_ZTEST_ASSERT_HOOK=y into prj.conf

Step2: Include <ztest_assert_hook.h> in your C code.

Step3: (optional) Define a hook function call ztest_post_assert_fail_hook().

Step4: call ztest_set_assert_valid(true) before where your target function
       call.


You can choose to use one or both of them, depending on your needs.
If you use none of them, you can still define your own fatal or assert handler
as usual.


Test example in this test set
=============================

This test verifies if the common fatal error and assert fail handler works.
If the expected error was caught, the test case will pass.

test_catch_assert_fail
  - To call a function then giving the condition to trigger the assert fail,
    then catch it by the assert handler.

test_catch_fatal_error
  - start a thread to test triggerring a null address dereferencing, then catch
    the (expected) fatal error.
  - start a thread to test triggerring an illegal instruction, then catch
    the (expected) fatal error.
  - start a thread to test triggerring a divide-by-zero error, then catch
    the (expected) fatal error.
  - start a thread to call k_oops() then catch the (expected) fatal error.
  - start a thread to call k_panel() then catch the (expected) fatal error.

test_catch_assert_in_isr
  - start a thread to enter ISR context by calling irq_offload(), then trigger
    an assert fail then catch it.

test_catch_z_oops
  - Pass illegal address by syscall, then inside the syscall handler, the
    Z_OOPS macro will trigger a fatal error that will get caught (as expected).



Limitation of this usage
========================

Trigger a fatal error in ISR context, that will cause problem due to
the interrupt stack is already abnormal when we want to continue other
test case, we do not recover it so far.


---------------------------------------------------------------------------

Sample Output:
{'fraction_non_alphanumeric': 0.08576755748912368, 'fraction_numerical': 0.002486016159105034, 'mean_word_length': 3.6951130561633843, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1988434', 'n_tokens_mistral': 1726, 'n_tokens_neox': 1656, 'n_words': 945}