Throwing and catching deliberate errors in bash

Question

Hello,
In many languages one can throw deliberate errors of a specific kind as well as catch-trap for specific errors. I'm having a hard time determining how to do this in bash 3.2 with it's 'trap' command.
Moreover, I can't figure out whether or not if it's even possible to catch for specific thrown errors defined by a scripter in bash. My own tests have led to a dead end and I haven't come any better understanding from reading the bash info docs, and numerous online and in print examples of the 'trap' command.
Basically, I wish to...
1. First, have scripts throw a specifically, identifiable, unique error when a certain known bad state has been encountered that they can't handle.
2. Secondly, to able to test for whether scripts are throwing an specific error under a certain condition.
3. Trap for and catch only that specific error and then keep on going, performing further automated tests.
Is this possible in bash?
Below is an example which might better illustrate what I've attempted to do. It unfortunately, doesn't do what's needed at the moment. i.e.- It will catch all errors and exits but not a specific one.
#--- The example below traps all errors but not the specific one.
particular_function()
current_status="some known bad condition"
if [ "$current_status" = "some known bad condition" ]; then
# Encountered some known condition we can't handle so throw specific error.
echo "Encountered a, we knew this would happen, type error."
exit -99
fi
testmethod_for_expectederror()
trap 'echo "function threw expected error code as it should."' EXIT
particular_function
testmethod_for_expectederror
echo "Continued passed caught error as desired and continuing further tests..."
Thanks,
-Anthony

Answer 1

{quote:title=BobHarris wrote:}The bash trap statement was not intended as an alternate way to return errors.
But if you want to generate your own signals, then use the kill command.
See "man 1 kill". {quote}
It sounds like I'm attempting to pound a square peg through a round hole? Attempting workarounds, like shaving off the corners of the peg, might eventually just lead to loss of sanity, time wasted - gone forever, never to return.
So, perhaps I'll try some other method.
If it offers a little more clarity, I'm trying determine [how to write tests|http://xp123.com/xplor/xp0101/index.shtml|Test-First Stoplight - write a test first before writing a line of code.], in bash, for situations where a script [should halt executing|http://xunitpatterns.com/Test%20Method.html#Expected%20Exception%20Te st|Expected exception test pattern] when it encounters something it can't handle rather than keep on going causing potential mishaps.
Basically, I would like to avoid causing the [xUnit testing framework|http://www.martinfowler.com/bliki/Xunit.html|xUnit testing frameworks in XP] I'm using [(shUnit2)|http://code.google.com/p/shunit2/|shUnit2 project site] from incorrectly reporting expected errors, that are suppose to be thrown, by a script, as failures. An expected, [correctly thrown error|http://books.google.ca/books?id=gFgndevwMAC&pg=PA163&lpg=PA163&dq=%22exceptiontest%22+%22test+driven+development%22patterns&source=bl&ots=enHrtsSunH&sig=PbbvWbea_VkqVAbdGYZwJDUcygI&hl=en&ei=XQslS qzSDs-EmQfIvqCFCA&sa=X&oi=bookresult&ct=result&resnum=1|Catch expected exceptions and ignore them. in TDD by Kent Beck] should be counted as a success by the framework in that context. Assuming, the script didn't exit in a bad way. At the same time, unforeseen errors should not be blocked and should propagate up to be reported as an erring test.
Thanks for your help,
-Anthony