ThrowTheSwitch/cexception
1
0
Fork 0
mirror of https://github.com/throwtheswitch/cexception.git synced 2026-06-05 21:24:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update CException to use Ceedling for testing. Why keep all of its own infrastructure when it's simpler to do this for the few of us actually developing CException?

Browse Source
This commit is contained in:
mvandervoord
2019-12-03 18:22:57 -05:00
parent e78c5aacc7
commit 632d980166
10 changed files with 205 additions and 210 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+1 -1
View File
@@ -1 +1 @@
*.out
build
.gitmodules
-3
View File
@@ -1,3 +0,0 @@
[submodule "vendor/unity"]
path = vendor/unity
url = https://github.com/throwtheswitch/unity.git
.travis.yml
+13 -5
View File
@@ -1,8 +1,16 @@
language: ruby
sudo: required
language: ruby c
os:
- linux
rvm:
- "1.9.3"
- "2.0.0"
- "2.3"
- "2.4"
- "2.6"
install:
- bundle install
- gem install ceedling
script:
- bundle exec rake ci
- ceedling clobber test:all
README.md
+154 -67
View File
@@ -1,139 +1,227 @@
CException - Lightweight exception library for C
================================================
[![CException Build Status](https://api.travis-ci.org/ThrowTheSwitch/CException.png?branch=master)](https://travis-ci.org/ThrowTheSwitch/CException)
_This Documentation Is Released Under a Creative Commons 3.0 Attribution Share-Alike License_
CException is simple exception handling in C. It is significantly faster than full-blown C++ exception handling but loses some flexibility. It is portable to any platform supporting `setjmp`/`longjmp`.
CException is simple exception handling in C. It is significantly faster than full-blown C++ exception handling
but loses some flexibility. It is portable to any platform supporting `setjmp`/`longjmp`.
Getting Started
================
The simplest way to get started is to just grab the code and pull it into your project:
> git clone --recursive https://github.com/throwtheswitch/cexception.git
If you want to contribute to this project, you'll also need to have Ruby installed to run the unit tests. You can automatically
install all the things you need by doing this:
```
git clone https://github.com/throwtheswitch/cexception.git
```
> cd cexception
> bundle install # Ensures you have all RubyGems needed
> bundle exec rake # Run CException tests
If you want to contribute to this project, you'll also need to have Ruby and Ceedling installed to run the unit tests.
Usage
=====
*_So what's it good for?_*
### So what's it good for?
Mostly error handling. Passing errors down a long chain of function calls gets ugly. Sometimes really ugly. So what if you could just specify certain places where you want to handle errors, and all your errors were transferred there? Let's try a lame example:
Mostly error handling. Passing errors down a long chain of function calls gets ugly. Sometimes really ugly.
So what if you could just specify certain places where you want to handle errors, and all your errors were
transferred there? Let's try a lame example:
CException uses C standard library functions setjmp and longjmp to operate. As long as the target system has these two functions defined, this library should be useable with very little configuration. It even supports environments where multiple program flows are in use, such as real-time operating systems... we started this project for use in embedded systems... but it obviously can be used for larger systems too.
CException uses C standard library functions setjmp and longjmp to operate. As long as the target system
has these two functions defined, this library should be useable with very little configuration. It even
supports environments where multiple program flows are in use, such as real-time operating systems...
we started this project for use in embedded systems... but it obviously can be used for larger systems too.
*_Error Handling with CException:_*
### Error Handling with CException:
```
void functionC(void) {
//do some stuff
if (there_was_a_problem)
Throw(ERR_BAD_BREATH);
//this stuff never gets called because of error
Throw(ERR_BAD_BREATH);
//this stuff never gets called because of error
}
```
There are about a gajillion exception frameworks using a similar setjmp/longjmp method out there... and there will probably be more in the future. Unfortunately, when we started our last embedded project, all those that existed either (a) did not support multiple tasks (therefore multiple stacks) or (b) were way more complex than we really wanted. CException was born.
There are about a gajillion exception frameworks using a similar setjmp/longjmp method out there... and there
will probably be more in the future. Unfortunately, when we started our last embedded project, all those that
existed either (a) did not support multiple tasks (therefore multiple stacks) or (b) were way more complex
than we really wanted. CException was born.
Why?
====
* It's ANSI C, and it beats passing error codes around.
### It's ANSI C
* *You want something simple...* CException throws a single id. You can define those ID's to be whatever you like. You might even choose which type that number is for your project. But that's as far as it goes. We weren't interested in passing objects or structs or strings... just simple error codes. Fast. Easy to Use. Easy to Understand.
...and it beats passing error codes around.
* *Performance...* CException can be configured for single tasking or multitasking. In single tasking, there is very little overhead past the setjmp/longjmp calls (which are already fast). In multitasking, your only additional overhead is the time it takes you to determine a unique task id (0 to num_tasks).
### You want something simple...
CException throws a single id. You can define those ID's to be whatever you like.
You might even choose which type that number is for your project. But that's as far as it goes. We weren't interested
in passing objects or structs or strings... just simple error codes. Fast. Easy to Use. Easy to Understand.
### Performance...
CException can be configured for single tasking or multitasking. In single tasking, there is
very little overhead past the setjmp/longjmp calls (which are already fast). In multitasking, your only additional
overhead is the time it takes you to determine a unique task id (0 to num_tasks).
How?
====
Code that is to be protected are wrapped in `Try { }` blocks. The code inside the Try block is _protected_, meaning that if any Throws occur, program control is directly transferred to the start of the Catch block. The Catch block immediately follows the Try block. It's ignored if no errors have occurred.
Code that is to be protected are wrapped in `Try { }` blocks. The code inside the Try block is _protected_,
meaning that if any Throws occur, program control is directly transferred to the start of the Catch block.
The Catch block immediately follows the Try block. It's ignored if no errors have occurred.
A numerical exception ID is included with Throw, and is passed into the Catch block. This allows you to handle errors differently or to report which error has occurred... or maybe it just makes debugging easier so you know where the problem was Thrown.
A numerical exception ID is included with Throw, and is passed into the Catch block. This allows you to handle
errors differently or to report which error has occurred... or maybe it just makes debugging easier so you
know where the problem was Thrown.
Throws can occur from anywhere inside the Try block, directly in the function you're testing or even within function calls (nested as deeply as you like). There can be as many Throws as you like, just remember that execution of the guts of your Try block ends as soon as the first Throw is triggered. Once you throw, you're transferred to the Catch block. A silly example:
Throws can occur from anywhere inside the Try block, directly in the function you're testing or even within
function calls (nested as deeply as you like). There can be as many Throws as you like, just remember that
execution of the guts of your Try block ends as soon as the first Throw is triggered. Once you throw, you're
transferred to the Catch block. A silly example:
```
void SillyExampleWhichPrintsZeroThroughFive(void) {
CEXCEPTION_T e;
int i;
while (i = 0; i < 6; i++) {
Try {
Throw(i);
//This spot is never reached
} Catch(e) {
printf(“%i “, e);
}
Try {
Throw(i);
//This spot is never reached
}
Catch(e) {
printf(“%i “, e);
}
}
}
```
Limitations
===========
This library was made to be as fast as possible, and provide basic exception handling. It is not a full-blown exception library like C++. Because of this, there are a few limitations that should be observed in order to successfully utilize this library:
This library was made to be as fast as possible, and provide basic exception handling. It is not a full-blown
exception library like C++. Because of this, there are a few limitations that should be observed in order to
successfully utilize this library:
* Do not directly `return` from within a `Try` block, nor `goto` into or out of a `Try` block.
* The `Try` macro allocates some local memory and alters a global pointer. These are cleaned up at the top of the `Catch` macro. Gotos and returns would bypass some of these steps, resulting in memory leaks or unpredictable behavior.
### Return & Goto
* If (a) you change local (stack) variables within your `Try` block, and (b) wish to make use of the updated values after an exception is thrown, those variables should be made `volatile`.
* Note that this is ONLY for locals and ONLY when you need access to them after a `Throw`.
* Compilers optimize (and thank goodness they do). There is no way to guarantee that the actual memory location was updated and not just a register unless the variable is marked volatile.
Do not directly `return` from within a `Try` block, nor `goto` into or out of a `Try` block.
The `Try` macro allocates some local memory and alters a global pointer. These are cleaned up at the
top of the `Catch` macro. Gotos and returns would bypass some of these steps, resulting in memory leaks
or unpredictable behavior.
* Memory which is `malloc`'d within a `Try` block is not automatically released when an error is thrown. This will sometimes be desirable, and othertimes may not. It will be the responsibility of the code you put in the `Catch` block to perform this kind of cleanup.
* There's just no easy way to track `malloc`'d memory, etc., without replacing or wrapping `malloc` calls or something like that. This is a lightweight framework, so these options were not desirable.
### Local Variables
If (a) you change local (stack) variables within your `Try` block, and (b) wish to make use of the updated
values after an exception is thrown, those variables should be made `volatile`.
Note that this is ONLY for locals and ONLY when you need access to them after a `Throw`.
Compilers optimize (and thank goodness they do). There is no way to guarantee that the actual memory
location was updated and not just a register unless the variable is marked volatile.
### Memory Management
Memory which is `malloc`'d within a `Try` block is not automatically released when an error is thrown. This
will sometimes be desirable, and othertimes may not. It will be the responsibility of the code you put in
the `Catch` block to perform this kind of cleanup.
There's just no easy way to track `malloc`'d memory, etc., without replacing or wrapping `malloc`
calls or something like that. This is a lightweight framework, so these options were not desirable.
CException API
==============
* `Try { ... }`
* `Try` is a macro which starts a protected block. It MUST be followed by a pair of braces or a single protected line (similar to an 'if'), enclosing the data that is to be protected. It MUST be followed by a `Catch` block (don't worry, you'll get compiler errors to let you know if you mess any of that up).
* The `Try` block is your protected block. It contains your main program flow, where you can ignore errors (other than a quick `Throw` call). You may nest multiple `Try` blocks if you want to handle errors at multiple levels, and you can even rethrow an error from within a nested `Catch`.
### `Try { ... }`
* `Catch(e) { }`
* `Catch` is a macro which ends the `Try` block and starts the error handling block. The `Catch` block is executed if and only if an exception was thrown while within the `Try` block. This error was thrown by a `Throw` call somewhere within `Try` (or within a function called within `Try`, or a function called by a function called within `Try`... you get the idea.).
* `Catch` receives a single id of type `CEXCEPTION_T` which you can ignore or use to handle the error in some way. You may throw errors from within Catches, but they will be caught by a `Try` wrapping the `Catch`, not the one immediately preceeding.
`Try` is a macro which starts a protected block. It MUST be followed by a pair of braces or a single
protected line (similar to an 'if'), enclosing the data that is to be protected. It MUST be followed by
a `Catch` block (don't worry, you'll get compiler errors to let you know if you mess any of that up).
* `Throw(e)`
* `Throw` is the method used to throw an error. `Throw`s should only occur from within a protected (`Try`...`Catch`) block, though it may easily be nested many function calls deep without an impact on performance or functionality. `Throw` takes a single argument, which is an exception id which will be passed to `Catch` as the reason for the error. If you wish to _re-throw_ an error, this can be done by calling `Throw(e)` with the error code you just caught. It _IS_ valid to throw from a `Catch` block.
The `Try` block is your protected block. It contains your main program flow, where you can ignore errors
(other than a quick `Throw` call). You may nest multiple `Try` blocks if you want to handle errors at
multiple levels, and you can even rethrow an error from within a nested `Catch`.
* `ExitTry()`
* `ExitTry` is a method used to immediately exit your current Try block but NOT treat this as an error. Don't run the Catch. Just start executing from after the Catch as if nothing had happened.
### `Catch(e) { }`
`Catch` is a macro which ends the `Try` block and starts the error handling block. The `Catch` block
is executed if and only if an exception was thrown while within the `Try` block. This error was thrown
by a `Throw` call somewhere within `Try` (or within a function called within `Try`, or a function called
by a function called within `Try`... you get the idea.).
`Catch` receives a single id of type `CEXCEPTION_T` which you can ignore or use to handle the error in
some way. You may throw errors from within Catches, but they will be caught by a `Try` wrapping the `Catch`,
not the one immediately preceeding.
### `Throw(e)`
`Throw` is the method used to throw an error. `Throw`s should only occur from within a protected
(`Try`...`Catch`) block, though it may easily be nested many function calls deep without an impact
on performance or functionality. `Throw` takes a single argument, which is an exception id which will be
passed to `Catch` as the reason for the error. If you wish to _re-throw_ an error, this can be done by
calling `Throw(e)` with the error code you just caught. It _IS_ valid to throw from a `Catch` block.
### `ExitTry()`
`ExitTry` is a method used to immediately exit your current Try block but NOT treat this as an error. Don't
run the Catch. Just start executing from after the Catch as if nothing had happened.
Configuration
=============
CException is a mostly portable library. It has one universal dependency, plus some macros which are required if working in a multi-tasking environment.
CException is a mostly portable library. It has one universal dependency, plus some macros which are required if
working in a multi-tasking environment.
The standard C library setjmp must be available. Since this is part of the standard library, it's all good.
If working in a multitasking environment, you need a stack frame for each task. Therefore, you must define methods for obtaining an index into an array of frames and to get the overall number of id's are required. If the OS supports a method to retrieve task ID's, and those tasks are number 0, 1, 2... you are in an ideal situation. Otherwise, a more creative mapping function may be required. Note that this function is likely to be called twice for each protected block and once during a throw. This is the only added overhead in the system.
If working in a multitasking environment, you need a stack frame for each task. Therefore, you must define
methods for obtaining an index into an array of frames and to get the overall number of id's are required. If
the OS supports a method to retrieve task ID's, and those tasks are number 0, 1, 2... you are in an ideal
situation. Otherwise, a more creative mapping function may be required. Note that this function is likely to
be called twice for each protected block and once during a throw. This is the only added overhead in the system.
You have options for configuring the library, if the defaults aren't good enough for you. You can add defines at the command prompt directly. You can always include a configuration file before including `CException.h`. You can make sure `CEXCEPTION_USE_CONFIG_FILE` is defined, which will force make CException look for `CExceptionConfig.h`, where you can define whatever you like. However you do it, you can override any or all of the following:
You have options for configuring the library, if the defaults aren't good enough for you. You can add defines
at the command prompt directly. You can always include a configuration file before including `CException.h`.
You can make sure `CEXCEPTION_USE_CONFIG_FILE` is defined, which will force make CException look for
`CExceptionConfig.h`, where you can define whatever you like. However you do it, you can override any or
all of the following:
* `CEXCEPTION_T`
* Set this to the type you want your exception id's to be. Defaults to an 'unsigned int'.
### `CEXCEPTION_T`
* `CEXCEPTION_NONE`
* Set this to a number which will never be an exception id in your system. Defaults to `0x5a5a5a5a`.
Set this to the type you want your exception id's to be. Defaults to an 'unsigned int'.
* `CEXCEPTION_GET_ID`
* If in a multi-tasking environment, this should be set to be a call to the function described in #2 above. It defaults to just return 0 all the time (good for single tasking environments, not so good otherwise).
### `CEXCEPTION_NONE`
* `CEXCEPTION_NUM_ID`
* If in a multi-tasking environment, this should be set to the number of ID's required (usually the number of tasks in the system). Defaults to 1 (good for single tasking environments or systems where you will only use this from one task).
Set this to a number which will never be an exception id in your system. Defaults to `0x5a5a5a5a`.
* `CEXCEPTION_NO_CATCH_HANDLER (id)`
* This macro can be optionally specified. It allows you to specify code to be called when a Throw is made outside of Try...Catch protection. Consider this the emergency fallback plan for when something has gone terribly wrong.
### `CEXCEPTION_GET_ID`
You may also want to include any header files which will commonly be needed by the rest of your application where it uses exception handling here. For example, OS header files or exception codes would be useful.
If in a multi-tasking environment, this should be set to be a call to the function described in #2 above.
It defaults to just return 0 all the time (good for single tasking environments, not so good otherwise).
Finally, there are some hook macros which you can implement to inject your own target-specific code in particular places. It is a rare instance where you will need these, but they are here if you need them:
### `CEXCEPTION_NUM_ID`
If in a multi-tasking environment, this should be set to the number of ID's required (usually the number
of tasks in the system). Defaults to 1 (good for single tasking environments or systems where you will only
use this from one task).
### `CEXCEPTION_NO_CATCH_HANDLER (id)`
This macro can be optionally specified. It allows you to specify code to be called when a Throw is made
outside of Try...Catch protection. Consider this the emergency fallback plan for when something has gone
terribly wrong.
### And More!
You may also want to include any header files which will commonly be needed by the rest of your application
where it uses exception handling here. For example, OS header files or exception codes would be useful.
Finally, there are some hook macros which you can implement to inject your own target-specific code in
particular places. It is a rare instance where you will need these, but they are here if you need them:
* `CEXCEPTION_HOOK_START_TRY` - called immediately before the Try block
* `CEXCEPTION_HOOK_HAPPY_TRY` - called immediately after the Try block if no exception was thrown
@@ -143,18 +231,17 @@ Finally, there are some hook macros which you can implement to inject your own t
Testing
=======
If you want to validate that CException works with your tools or that it works with your custom configuration, you may want to run the included test suite. This is the test suite (along with real projects we've used it on) that we use to make sure that things actually work the way we claim.
The test suite included makes use of the Unity Test Framework. It will require a native C compiler. The example makefile and rakefile both use MinGW's gcc. Modify either to include the proper paths to tools, then run `make` to compile and run the test application.
* `C_COMPILER` - The C compiler to use to perform the tests.
* `C_LIBS` - The path to the C libraries (including setjmp).
* `UNITY_DIR` - The path to the Unity framework (required to run tests)
If you want to validate that CException works with your tools or that it works with your custom
configuration, you may want to run the included test suite. This is the test suite (along with real
projects we've used it on) that we use to make sure that things actually work the way we claim.
The test suite makes use of Ceedling, which uses the Unity Test Framework. It will require a native C compiler.
The example makefile and rakefile both use gcc.
License
=======
*This software is licensed under the MIT License:
Copyright (c) 2007-2017 Mark VanderVoord*
Copyright (c) 2007-2019 Mark VanderVoord*
*Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.*
Rakefile
-42
View File
@@ -1,42 +0,0 @@
HERE = File.expand_path(File.dirname(__FILE__)) + '/'
require 'rake'
require 'rake/clean'
require 'rake/testtask'
require HERE+'vendor/unity/auto/colour_reporter.rb'
#Tool and Lib Locations
C_COMPILER = 'gcc'
C_LIBS = ''
UNITY_DIR = 'vendor/unity/src'
#Test File To Be Created
OUT_FILE = 'test_cexceptions'
OUT_EXTENSION = '.out'
#Options
SRC_FILES = "lib/CException.c test/TestException.c test/TestException_Runner.c #{UNITY_DIR}/unity.c"
INC_DIRS = "-Ilib -Itest -I#{UNITY_DIR}"
LIB_DIRS = C_LIBS.empty? ? '' : "-L#{C_LIBS}"
SYMBOLS = '-DTEST -DCEXCEPTION_USE_CONFIG_FILE'
CLEAN.include("#{HERE}*.out")
task :no_color do
$colour_output = false
end
desc "performs a quick set of unit tests to confirm you're ready to go"
task :test do
report "#{C_COMPILER} #{INC_DIRS} #{LIB_DIRS} #{SYMBOLS} #{SRC_FILES} -o #{OUT_FILE}#{OUT_EXTENSION}"
output = `#{C_COMPILER} #{INC_DIRS} #{LIB_DIRS} #{SYMBOLS} #{SRC_FILES} -o #{OUT_FILE}#{OUT_EXTENSION}`
report output
report "#{HERE}#{OUT_FILE}#{OUT_EXTENSION}"
output = `#{HERE}#{OUT_FILE}#{OUT_EXTENSION}`
report output
end
task :default => [:clobber, :test]
task :ci => [:no_color, :default]
task :cruise => :ci
makefile
-24
View File
@@ -1,24 +0,0 @@
#Tool and Lib Locations
C_COMPILER=gcc
C_LIBS=C:/MinGW/lib
UNITY_DIR=vendor/unity/src
#Test File To Be Created
OUT_FILE=test_cexceptions
ifeq ($(OS),Windows_NT)
OUT_EXTENSION=.exe
else
OUT_EXTENSION=.out
endif
#Options
SRC_FILES=lib/CException.c test/TestException.c test/TestException_Runner.c $(UNITY_DIR)/unity.c
INC_DIRS=-Ilib -Itest -I$(UNITY_DIR)
LIB_DIRS=-L$(C_LIBS)
SYMBOLS=-DTEST -DCEXCEPTION_USE_CONFIG_FILE
#Default Task: Compile And Run Tests
default:
$(C_COMPILER) $(INC_DIRS) $(LIB_DIRS) $(SYMBOLS) $(SRC_FILES) -o $(OUT_FILE)$(OUT_EXTENSION)
$(OUT_FILE)$(OUT_EXTENSION)
project.yml
+37
View File
@@ -0,0 +1,37 @@
---
# This project file is for using Ceedling to run CException's self-tests. The
# only requirement for USING CException is in the lib folder.
:project:
:use_exceptions: FALSE
:use_test_preprocessor: FALSE
:use_auxiliary_dependencies: FALSE
:build_root: build
:test_file_prefix: Test
:which_ceedling: gem
:ceedling_version: 0.29.1
:default_tasks:
- clobber test:all
:extension:
:executable: .out
:paths:
:test:
- +:test/**
- -:test/support
:source:
- lib/**
:support:
- test/support
:defines:
:test:
- TEST
- CEXCEPTION_USE_CONFIG_FILE
:test_preprocess:
- TEST
- CEXCEPTION_USE_CONFIG_FILE
...
test/TestException_Runner.c
-67
View File
@@ -1,67 +0,0 @@
/* AUTOGENERATED FILE. DO NOT EDIT. */
//=======Test Runner Used To Run Each Test Below=====
#define RUN_TEST(TestFunc, TestLineNum) \
{ \
Unity.CurrentTestName = #TestFunc; \
Unity.CurrentTestLineNumber = TestLineNum; \
Unity.NumberOfTests++; \
if (TEST_PROTECT()) \
{ \
setUp(); \
TestFunc(); \
} \
if (TEST_PROTECT() && !TEST_IS_IGNORED) \
{ \
tearDown(); \
} \
UnityConcludeTest(); \
}
//=======Automagically Detected Files To Include=====
#include "unity.h"
#include <setjmp.h>
#include <stdio.h>
//=======External Functions This Runner Calls=====
extern void setUp(void);
extern void tearDown(void);
extern void test_BasicTryDoesNothingIfNoThrow(void);
extern void test_BasicThrowAndCatch(void);
extern void test_BasicThrowAndCatch_WithMiniSyntax(void);
extern void test_VerifyVolatilesSurviveThrowAndCatch(void);
extern void test_ThrowFromASubFunctionAndCatchInRootFunc(void);
extern void test_ThrowAndCatchFromASubFunctionAndRethrowToCatchInRootFunc(void);
extern void test_ThrowAndCatchFromASubFunctionAndNoRethrowToCatchInRootFunc(void);
extern void test_ThrowAnErrorThenEnterATryBlockFromWithinCatch_VerifyThisDoesntCorruptExceptionId(void);
extern void test_ThrowAnErrorThenEnterATryBlockFromWithinCatch_VerifyThatEachExceptionIdIndependent(void);
extern void test_CanHaveMultipleTryBlocksInASingleFunction(void);
extern void test_CanHaveNestedTryBlocksInASingleFunction_ThrowInside(void);
extern void test_CanHaveNestedTryBlocksInASingleFunction_ThrowOutside(void);
extern void test_AThrowWithoutATryCatchWillUseDefaultHandlerIfSpecified(void);
extern void test_AThrowWithoutOutsideATryCatchWillUseDefaultHandlerEvenAfterTryCatch(void);
extern void test_AbilityToExitTryWithoutThrowingAnError(void);
extern void test_AbilityToExitTryWillOnlyExitOneLevel(void);
//=======MAIN=====
int main(void)
{
UnityBegin("TestException.c");
RUN_TEST(test_BasicTryDoesNothingIfNoThrow, 16);
RUN_TEST(test_BasicThrowAndCatch, 37);
RUN_TEST(test_BasicThrowAndCatch_WithMiniSyntax, 56);
RUN_TEST(test_VerifyVolatilesSurviveThrowAndCatch, 76);
RUN_TEST(test_ThrowFromASubFunctionAndCatchInRootFunc, 105);
RUN_TEST(test_ThrowAndCatchFromASubFunctionAndRethrowToCatchInRootFunc, 148);
RUN_TEST(test_ThrowAndCatchFromASubFunctionAndNoRethrowToCatchInRootFunc, 167);
RUN_TEST(test_ThrowAnErrorThenEnterATryBlockFromWithinCatch_VerifyThisDoesntCorruptExceptionId, 184);
RUN_TEST(test_ThrowAnErrorThenEnterATryBlockFromWithinCatch_VerifyThatEachExceptionIdIndependent, 202);
RUN_TEST(test_CanHaveMultipleTryBlocksInASingleFunction, 229);
RUN_TEST(test_CanHaveNestedTryBlocksInASingleFunction_ThrowInside, 254);
RUN_TEST(test_CanHaveNestedTryBlocksInASingleFunction_ThrowOutside, 281);
RUN_TEST(test_AThrowWithoutATryCatchWillUseDefaultHandlerIfSpecified, 308);
RUN_TEST(test_AThrowWithoutOutsideATryCatchWillUseDefaultHandlerEvenAfterTryCatch, 319);
RUN_TEST(test_AbilityToExitTryWithoutThrowingAnError, 344);
RUN_TEST(test_AbilityToExitTryWillOnlyExitOneLevel, 363);
return (UnityEnd());
}
test/CExceptionConfig.h → test/support/CExceptionConfig.h
View File
vendor/unity
Vendored
-1
Submodule vendor/unity deleted from 2c7629a0ae