Correct Way of Handling Exception

[Ami]

We have an application where in SOAP is used as a middle layer to
communication between Java Front layer and DCE( Distributed Computing
Env) backend layer.
We are using Systinet Server for C++ to deploy our SOAP code and we
make DCE RPC call through our SOAP code in C++ to connect and SEND and
Retrieve Data from DCE.

Now we have to incorporate exception handling in such a way , if DCE
is down, then while making a DCERPC call SOAP Server should not dump
core.
IN our SIT testing , our SOAP Server is dumping while making a DCERPC
call.
Example for PRSJCalcDefAmt ( SOAP Mehtod ) which is making a DCE
call , from SOAP logs

Entering casclifService:RSJCalcDefAmt method ...
16607 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyERSMonEventServer
16608 22/10/2007 6:27:0>> Before the ESLogEvent Call ...
16609 22/10/2007 6:27:0>> After the ESLogEvent Call ...
16610 22/10/2007 6:27:0>>SECURE KEY Validation Successful
16611 22/10/2007 6:27:0>>Boff code from DCE.cpp = 0x40ff4dd3
16612 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyFECSSrvr
16613 22/10/2007 6:27:0>>Before Calling the DCE Method
PRSJCalcDefAmt ...
16614 Unhandled exception; exiting!
16615 Exception kind is status,value is 382312502. Thread 9 .
16616 ^[[H^[[2JTRIMSSecret.ini File is successfully opened

382312502 corresponds to rpc_s_connection_closed error.

We do not have yet any mechnism to catch such exception .

The SOAP code which causes the core dump is as below
long tResult = PR_SJCalcDefAmt( hndlr,
(long)p_nbr_PartSyndCda,
p_str_part_synd_cda,
p_str_lc_details,
(long)p_nbr_Guarantors,
p_str_guarantors,
&p_str_guarantors_listOut,
&p_str_ErrorMsg,
(unsigned char *)p_txt_ApplErrorMsg,
(unsigned char *)user_id,
&p_cod_Error);

we tried the following
try
{
tResult = PR_SJCalcDefAmt(hndlr,
(long)p_nbr_PartSyndCda,
p_str_part_synd_cda,
p_str_lc_details,
(long)p_nbr_Guarantors,
p_str_guarantors,
&p_str_guarantors_listOut,
&p_str_ErrorMsg,
(unsigned char *)p_txt_ApplErrorMsg,
(unsigned char *)user_id,
&p_cod_Error);
}
catch(...)
{
PRINT("Un Handled Exception Occured");
TrimsCustomException * exc = new TrimsCustomException();
exc->msgId="SSCDCEEXP003";
exc->msgText="Unhandled Exception";
arm_stop(cas_start_handle,ARM_ABORT, 0, 0, 0);
free(p_str_part_synd_cda);
free(p_str_lc_details);
free(p_str_guarantors);
free(p_str_guarantors_listOut);
free(user_id);
throw exc;
}

The exception call is defined as below
// Exception Class Definition

public class TRIMSSOAPException extends javax.xml.soap.SOAPException
{
public String msgID;
public String msgText;

public TRIMSSOAPException ()
{
super("SOAP CUSTOM EXCEPTION");
}

public TRIMSSOAPException (String ID, String Text)
{
msgID=ID;
msgText=Text;
super("SOAP CUSTOM EXCEPTION");
}

public String getMsgID()
{
return msgID;
}
public String getMsgText()
{
return msgText;
}
}
the SOAP server will raise TRIMSSOAPException and populate msgID and
msgText appropriately which will be caught by Java client and further
action would be decided based on the msgID values and msgText may be
used to display error message to application user.

Still SOAP core is dumping in spite of adding above exception.
Please let me know other way of handling exception
Thanks

 

[Jonathan Mcdougall]

We have an application where in SOAP is used as a middle layer to
communication between Java Front layer and DCE( Distributed Computing
Env) backend layer.

This newsgroup discusses the C++ language itself. Please see
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9
for newsgroup suggestions.

 

[Alf P. Steinbach]

* Ami:

We have an application where in SOAP is used as a middle layer to
communication between Java Front layer and DCE( Distributed Computing
Env) backend layer.
We are using Systinet Server for C++ to deploy our SOAP code and we
make DCE RPC call through our SOAP code in C++ to connect and SEND and
Retrieve Data from DCE.

Now we have to incorporate exception handling in such a way , if DCE
is down, then while making a DCERPC call SOAP Server should not dump
core.
IN our SIT testing , our SOAP Server is dumping while making a DCERPC
call.
Example for PRSJCalcDefAmt ( SOAP Mehtod ) which is making a DCE
call , from SOAP logs

Entering casclifService:RSJCalcDefAmt method ...
16607 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyERSMonEventServer
16608 22/10/2007 6:27:0>> Before the ESLogEvent Call ...
16609 22/10/2007 6:27:0>> After the ESLogEvent Call ...
16610 22/10/2007 6:27:0>>SECURE KEY Validation Successful
16611 22/10/2007 6:27:0>>Boff code from DCE.cpp = 0x40ff4dd3
16612 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyFECSSrvr
16613 22/10/2007 6:27:0>>Before Calling the DCE Method
PRSJCalcDefAmt ...
16614 Unhandled exception; exiting!
16615 Exception kind is status,value is 382312502. Thread 9 .
16616 ^[[H^[[2JTRIMSSecret.ini File is successfully opened

382312502 corresponds to rpc_s_connection_closed error.

We do not have yet any mechnism to catch such exception .

The SOAP code which causes the core dump is as below
long tResult = PR_SJCalcDefAmt( hndlr,
(long)p_nbr_PartSyndCda,
p_str_part_synd_cda,
p_str_lc_details,
(long)p_nbr_Guarantors,
p_str_guarantors,
&p_str_guarantors_listOut,
&p_str_ErrorMsg,
(unsigned char *)p_txt_ApplErrorMsg,
(unsigned char *)user_id,
&p_cod_Error);

This is a function call. It doesn't tell anything other than that the
code is spaghetti and therefore probably chock full bugs.
Spaghetti-points: number of arguments, casts, pointer arguments, cryptic
names, hungarian notation, inconsistent naming conventions, prefixes
instead of namespaces, unproper indentation, three independent error
reporting mechanisms, so on.

we tried the following
try
{
tResult = PR_SJCalcDefAmt(hndlr,
(long)p_nbr_PartSyndCda,
p_str_part_synd_cda,
p_str_lc_details,
(long)p_nbr_Guarantors,
p_str_guarantors,
&p_str_guarantors_listOut,
&p_str_ErrorMsg,
(unsigned char *)p_txt_ApplErrorMsg,
(unsigned char *)user_id,
&p_cod_Error);
}
catch(...)
{
PRINT("Un Handled Exception Occured");
TrimsCustomException * exc = new TrimsCustomException();
exc->msgId="SSCDCEEXP003";
exc->msgText="Unhandled Exception";
arm_stop(cas_start_handle,ARM_ABORT, 0, 0, 0);
free(p_str_part_synd_cda);
free(p_str_lc_details);
free(p_str_guarantors);
free(p_str_guarantors_listOut);
free(user_id);

Use destructors (RAII idiom) instead of manual cleanup.

Use C++ new and delete instead of C malloc and free.

Use e.g. std::string instead of raw C strings.

throw exc;

Throwing a pointer to dynamically allocated object is an invitation to
disaster. The catch(...) clause illustrates one way that it can screw
things up. If this catch(...) catches a pointer to a dynamically
allocated exception object, that object won't be destroyed and
deallocated. Another way where it really screws things up is when the
exception object is deallocated twice. The pointer-throwing means there
is no firm responsibility for cleanup, and cleanup not automated: it's
all completely manual and wishy-washy.

}

The exception call is defined as below
// Exception Class Definition

public class TRIMSSOAPException extends javax.xml.soap.SOAPException

This code is Java, not C++.

{
public String msgID;
public String msgText;

public TRIMSSOAPException ()
{
super("SOAP CUSTOM EXCEPTION");
}

public TRIMSSOAPException (String ID, String Text)
{
msgID=ID;
msgText=Text;
super("SOAP CUSTOM EXCEPTION");
}

public String getMsgID()
{
return msgID;
}
public String getMsgText()
{
return msgText;
}
}
the SOAP server will raise TRIMSSOAPException and populate msgID and
msgText appropriately which will be caught by Java client and further
action would be decided based on the msgID values and msgText may be
used to display error message to application user.

Still SOAP core is dumping in spite of adding above exception.
Please let me know other way of handling exception
Thanks

As I recall simply throwing a pointer to some Java-compatible exception
object is not the way to propagate an exception up to Java.

Read up on your JNI documentation.

For the server stuff, please ask in appropriate groups; for JNI, please
ask in a Java group.


Cheers, & hth.,

- Alf

 

[Ami]

* Ami:

We have an application where in SOAP is used as a middle layer to
communication between Java Front layer and DCE( Distributed Computing
Env) backend layer.
We are using Systinet Server for C++ to deploy our SOAP code and we
make DCE RPC call through our SOAP code in C++ to connect and SEND and
Retrieve Data from DCE.

Now we have to incorporate exception handling in such a way , if DCE
is down, then while making a DCERPC call SOAP Server should not dump
core.
IN our SIT testing , our SOAP Server is dumping while making a DCERPC
call.
Example for PRSJCalcDefAmt ( SOAP Mehtod ) which is making a DCE
call , from SOAP logs

Entering casclifService:RSJCalcDefAmt method ...
16607 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyERSMonEventServer
16608 22/10/2007 6:27:0>> Before the ESLogEvent Call ...
16609 22/10/2007 6:27:0>> After the ESLogEvent Call ...
16610 22/10/2007 6:27:0>>SECURE KEY Validation Successful
16611 22/10/2007 6:27:0>>Boff code from DCE.cpp = 0x40ff4dd3
16612 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyFECSSrvr
16613 22/10/2007 6:27:0>>Before Calling the DCE Method
PRSJCalcDefAmt ...
16614 Unhandled exception; exiting!
16615 Exception kind is status,value is 382312502. Thread 9 .
16616 ^[[H^[[2JTRIMSSecret.ini File is successfully opened

382312502 corresponds to rpc_s_connection_closed error.

We do not have yet any mechnism to catch such exception .

The SOAP code which causes the core dump is as below
long tResult = PR_SJCalcDefAmt( hndlr,
(long)p_nbr_PartSyndCda,
p_str_part_synd_cda,
p_str_lc_details,
(long)p_nbr_Guarantors,
p_str_guarantors,
&p_str_guarantors_listOut,
&p_str_ErrorMsg,
(unsigned char *)p_txt_ApplErrorMsg,
(unsigned char *)user_id,
&p_cod_Error);

This is a function call. It doesn't tell anything other than that the
code is spaghetti and therefore probably chock full bugs.
Spaghetti-points: number of arguments, casts, pointer arguments, cryptic
names, hungarian notation, inconsistent naming conventions, prefixes
instead of namespaces, unproper indentation, three independent error
reporting mechanisms, so on.

we tried the following
try
{
tResult = PR_SJCalcDefAmt(hndlr,
(long)p_nbr_PartSyndCda,
p_str_part_synd_cda,
p_str_lc_details,
(long)p_nbr_Guarantors,
p_str_guarantors,
&p_str_guarantors_listOut,
&p_str_ErrorMsg,
(unsigned char *)p_txt_ApplErrorMsg,
(unsigned char *)user_id,
&p_cod_Error);
}
catch(...)
{
PRINT("Un Handled Exception Occured");
TrimsCustomException * exc = new TrimsCustomException();
exc->msgId="SSCDCEEXP003";
exc->msgText="Unhandled Exception";
arm_stop(cas_start_handle,ARM_ABORT, 0, 0, 0);
free(p_str_part_synd_cda);
free(p_str_lc_details);
free(p_str_guarantors);
free(p_str_guarantors_listOut);
free(user_id);

Use destructors (RAII idiom) instead of manual cleanup.

Use C++ new and delete instead of C malloc and free.

Use e.g. std::string instead of raw C strings.

throw exc;

Throwing a pointer to dynamically allocated object is an invitation to
disaster. The catch(...) clause illustrates one way that it can screw
things up. If this catch(...) catches a pointer to a dynamically
allocated exception object, that object won't be destroyed and
deallocated. Another way where it really screws things up is when the
exception object is deallocated twice. The pointer-throwing means there
is no firm responsibility for cleanup, and cleanup not automated: it's
all completely manual and wishy-washy.

}

The exception call is defined as below
// Exception Class Definition

public class TRIMSSOAPException extends javax.xml.soap.SOAPException

This code is Java, not C++.

{
public String msgID;
public String msgText;

public TRIMSSOAPException ()
{
super("SOAP CUSTOM EXCEPTION");
}

public TRIMSSOAPException (String ID, String Text)
{
msgID=ID;
msgText=Text;
super("SOAP CUSTOM EXCEPTION");
}

public String getMsgID()
{
return msgID;
}
public String getMsgText()
{
return msgText;
}
}
the SOAP server will raise TRIMSSOAPException and populate msgID and
msgText appropriately which will be caught by Java client and further
action would be decided based on the msgID values and msgText may be
used to display error message to application user.

Still SOAP core is dumping in spite of adding above exception.
Please let me know other way of handling exception
Thanks

As I recall simply throwing a pointer to some Java-compatible exception
object is not the way to propagate an exception up to Java.

Read up on your JNI documentation.

For the server stuff, please ask in appropriate groups; for JNI, please
ask in a Java group.

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Since it is the DCE which throws an exception 382312502 corresponds to
rpc_s_connection_closed error, there is an exception defined in
rpcexc.h for all the rpc related things. This header is available in /
opt/dce/include/dce.
RPC_EXTERN_EXCEPTION rpc_x_connection_closed; is defined in rpcexc.h .
It seems to be an NIDL (Network Interface Definition Language)
Exception. If we could find how to catch this exception then SOAP
Server can be prevented from DUMPING.
Still no idea on how to use this exception in my code.

 

[Abhishek Padmanabh]

* Ami:

We have an application where in SOAP is used as a middle layer to
communication between Java Front layer and DCE( Distributed Computing
Env) backend layer.
We are using Systinet Server for C++ to deploy our SOAP code and we
make DCE RPC call through our SOAP code in C++ to connect and SEND and
Retrieve Data from DCE.
Now we have to incorporate exception handling in such a way , if DCE
is down, then while making a DCERPC call SOAP Server should not dump
core.
IN our SIT testing , our SOAP Server is dumping while making a DCERPC
call.
Example for PRSJCalcDefAmt ( SOAP Mehtod ) which is making a DCE
call , from SOAP logs
Entering casclifService:RSJCalcDefAmt method ...
16607 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyERSMonEventServer
16608 22/10/2007 6:27:0>> Before the ESLogEvent Call ...
16609 22/10/2007 6:27:0>> After the ESLogEvent Call ...
16610 22/10/2007 6:27:0>>SECURE KEY Validation Successful
16611 22/10/2007 6:27:0>>Boff code from DCE.cpp = 0x40ff4dd3
16612 22/10/2007 6:27:0>>DCE Server is Running Fine for /.:/users/
trimsprd/dceOnlyFECSSrvr
16613 22/10/2007 6:27:0>>Before Calling the DCE Method
PRSJCalcDefAmt ...
16614 Unhandled exception; exiting!
16615 Exception kind is status,value is 382312502. Thread 9 .
16616 ^[[H^[[2JTRIMSSecret.ini File is successfully opened
382312502 corresponds to rpc_s_connection_closed error.
We do not have yet any mechnism to catch such exception .
The SOAP code which causes the core dump is as below
long tResult = PR_SJCalcDefAmt( hndlr,
(long)p_nbr_PartSyndCda,
p_str_part_synd_cda,
p_str_lc_details,
(long)p_nbr_Guarantors,
p_str_guarantors,
&p_str_guarantors_listOut,
&p_str_ErrorMsg,
(unsigned char *)p_txt_ApplErrorMsg,
(unsigned char *)user_id,
&p_cod_Error);

This is a function call. It doesn't tell anything other than that the
code is spaghetti and therefore probably chock full bugs.
Spaghetti-points: number of arguments, casts, pointer arguments, cryptic
names, hungarian notation, inconsistent naming conventions, prefixes
instead of namespaces, unproper indentation, three independent error
reporting mechanisms, so on.

Use destructors (RAII idiom) instead of manual cleanup.

Use C++ new and delete instead of C malloc and free.

Use e.g. std::string instead of raw C strings.

Throwing a pointer to dynamically allocated object is an invitation to
disaster. The catch(...) clause illustrates one way that it can screw
things up. If this catch(...) catches a pointer to a dynamically
allocated exception object, that object won't be destroyed and
deallocated. Another way where it really screws things up is when the
exception object is deallocated twice. The pointer-throwing means there
is no firm responsibility for cleanup, and cleanup not automated: it's
all completely manual and wishy-washy.

This code is Java, not C++.

As I recall simply throwing a pointer to some Java-compatible exception
object is not the way to propagate an exception up to Java.

Read up on your JNI documentation.

For the server stuff, please ask in appropriate groups; for JNI, please
ask in a Java group.

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Since it is the DCE which throws an exception 382312502 corresponds to
rpc_s_connection_closed error, there is an exception defined in
rpcexc.h for all the rpc related things. This header is available in /
opt/dce/include/dce .
RPC_EXTERN_EXCEPTION rpc_x_connection_closed; is defined in rpcexc.h .
It seems to be an NIDL (Network Interface Definition Language)
Exception. If we could find how to catch this exception then SOAP
Server can be prevented from DUMPING.
Still no idea on how to use this exception in my code.- Hide quoted text -

Look at this place which is logging the below:

16614 Unhandled exception; exiting!
16615 Exception kind is status,value is 382312502. Thread 9 .
16616 ^[[H^[[2JTRIMSSecret.ini File is successfully opened

This shows that the exception from the DCE server is properly being
translated and that should be the point where you should catch hold of
the problem. If this log is from Systinet infrastructure (that I think
you do not own) (this is less probable), there should be a way in
which it tells your C++ SOAP code about the problem and if it is from
your code, well you are not handling the response well. The only thing
that could be going wrong is that even after getting that error (which
is not really an exception when you recieve it), the processing inside
PRSJCalcDefAmt goes on as if everything was normal even after logging
the problem as above and causes a core dump.

Putting a try-catch(...) around the PRSJCalcDefAmt call will not help
because the exception from DCE server is not really a C++ exception
but just a byte stream/string response and your C++ code is probably
not translating that response into an exception.