How do I catch mixed signals?

[Ramon F Herrera]

I have been using the try...catch statement, with my own signals
(USER_NOT_FOUND, etc). I am also dealing with a date+time library
(from Boost) which raises its own exceptions (for instance, when a
month is out of range).

I am not sure whether I can catch both exceptions in the same
statement. Can I? How?

TIA,

-Ramon

[Francis Glassborow]

Not sure why you would want to do that but it can only be done if the
exception types have a common base class and you catch byu reference (to
that base)

In general you need one catch clause for each exception type.

[Ramon F Herrera]

On Nov 19, 5:28 am, Francis Glassborow

Point taken. I was just curious about the possibility that I was being
inefficient. I have been dealing with the try...catch statement for a
short time.

Thx,

-RFH

[Ulrich Eckhardt]

Ramon F Herrera wrote:
> I have been using the try...catch statement, with my own signals

Note: The term "signal" is used in different contexts, see the POSIX signal
function.

> (USER_NOT_FOUND, etc).

Note: It is customary to reserve ALL_UPPERCASE names for macros.

> I am also dealing with a date+time library (from Boost) which raises
> its own exceptions (for instance, when a month is out of range).
>
> I am not sure whether I can catch both exceptions in the same
> statement. Can I? How?

try {
...
} catch(std::exception const& e) {
...
}

This will catch all exceptions derived from std::exception. And you should
derive your own exceptions from that.

try {
...
} catch(boost::date_time_error const& e) {
...
} catch(user_not_found const& e) {
...
}

This allows you to catch both exceptions (or exceptions derived from them)
and to distinguish them at the same time. Note that the first catch that
matches will be taken, if you e.g. want a default catch using
std::exception, it must come last.

Uli

[stan]

Ulrich Eckhardt wrote:
> Ramon F Herrera wrote:
>> I have been using the try...catch statement, with my own signals
>
> Note: The term "signal" is used in different contexts, see the POSIX signal
> function.
>
>> (USER_NOT_FOUND, etc).
>
> Note: It is customary to reserve ALL_UPPERCASE names for macros.

When a magic number is defined as a constant, it's not uncommon to use
uppercase either. USER_NOT_FOUND sounds like a defined error or status
condition. But, I agree with the idea that uppercase should not be
random or haphazardly used unless you are trying to obfuscate. Reading
code, even your own, is hard enough without adding layers of problems.

[Alf P. Steinbach]

* stan:

> Ulrich Eckhardt wrote:
>> Ramon F Herrera wrote:
>>> I have been using the try...catch statement, with my own signals
>> Note: The term "signal" is used in different contexts, see the POSIX signal
>> function.
>>
>>> (USER_NOT_FOUND, etc).
>> Note: It is customary to reserve ALL_UPPERCASE names for macros.
>
> When a magic number is defined as a constant, it's not uncommon to use
> uppercase either.

Java programmers do that, yes.

C and C++ are different languages.

Java doesn't have a preprocessor. C and C++ do. Ironically Java's convention
stems from C, from the time where C didn't have constants so the preprocessor
had to be employed to emulate them.

> USER_NOT_FOUND sounds like a defined error or status
> condition. But, I agree with the idea that uppercase should not be
> random or haphazardly used unless you are trying to obfuscate. Reading
> code, even your own, is hard enough without adding layers of problems.

Yes. :-)

Cheers & hth.,

- Alf

[Keith Thompson]

"Alf P. Steinbach" <al...@start.no> writes:
[...]

> Java doesn't have a preprocessor. C and C++ do. Ironically Java's
> convention stems from C, from the time where C didn't have constants
> so the preprocessor had to be employed to emulate them.

[...]

C still doesn't really have symbolic constants. This:

const int answer = 42;

doesn't make ``answer'' a constant expression; this:

...
case answer:
...

is a constraint violation, and this:

int arr[answer];

is a VLA, legal only at block scope.

You can fake it with an enum:

enum { answer = 42 };

but that only gives you constants of type int.

You still have to use the preprocessor for symbolic constants in many
cases.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"