axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Sizer <...@15grant.com>
Subject Re: Suggestion on receiving soap fault
Date Fri, 07 May 2004 15:28:42 GMT
damitha@opensource.lk wrote:
>>Damitha,
>>    What is X in this case?
[snip]
> X in the first AXISC_THROW(X) (exception enabled case) is an int error
> code which already defined or any exception object(for example bad_cast)
> 
> in the seconde AXISC_THROW(X) (exception disabled) is an int error code

There are a couple of problems with this.

#1. All exceptions should be derived from std::exception - that allows 
easy integration into existing code that has catch ( std::exception& ) 
blocks. Don't throw ints - it defeats the purpose (i.e. all the 
additional information is lost and some sort of "getLastError()" thing 
has to implemented on top of the exception handling. Pick a method and 
stick with it.

#2. Exceptions should ALWAYS be caught by reference, not value, to avoid 
exception slicing.

#3. Personal opinion: Macros should be avoided at all costs. I wish C++ 
mode had a way to turn them off. They make for very difficult to manage 
code (one has to test all the macro paths [compile time] in addition to 
testing all the run-time paths). That's just my opinion, not widely 
held. #1 and #2 are "industry standard" stuff.

>>>>From non exception case:
>>
>>>#define AXISC_THROW(X) return X
>>
>>suggests that X must be int.
>>
>>If the exception model cannot use objects (i.e. throw and catch objects)
>>that is not that useful.
> 
> As you can see above you can throw and catch objects

You can, but it's VERY dangerous - catching, and rethrowing, can result 
in very unexpected behavior when done by value - the slicing problem (if 
you're not aware of it, I'd suggest a Google search - I don't have a 
good reference handy and I'm sure others have written about it better 
than I would here).

[snip]
(Others have further addressed the function vs procedure issue)

Addressing a point that got lost: C compatibility.

You really have to make a choice: C++ or C. Make it and stick with it - 
do NOT try to combine them (e.g. by having macros that throw integers).

If C compatibility is a primary design consideration, go with the return 
code. Consistency is vital. However, if you're going that route, I'd 
suggest using the new-ish error handling stuff that the gcc libraries 
use - they've dealt with many of the threading issues. (e.g. one does 
not reference _errno [or whatever it is, I haven't done C in years] 
directly any longer).

Good luck - it's easy to throw advice from the sidelines :)

- Mark


Mime
View raw message