Exiting a console app from deep in the code

Haha. I should have said I started C 37 years ago, added C++ 5 years later, and added Java in 1997 when it first became commercially stable. I also used 80x86 assembler during the PC DOS years. Before that, I did COBOL, BAL, and RPG II, with a bit of FORTRAN and EDL. It only SEEMS sometimes like I've been doing this for 89 years instead of 42.

I have continued to use C/C++ (an extension of C and a "better" C if you don't want to dance as much on the razor's edge ;) ) and Java regularly, often mixing them on the same projects, with plain old C still my favorite for its ability to go to such a low level and, under DOS, bypass both DOS and BIOS levels for efficiency. I have done a lot of digital video and financial algorithmic trading and datamining work that contains modules that Java is just not flexible enough to handle, so separate services are often done in different languages as needed.

The reason this came up was how to terminate if the sendmail method throws an exception. Originally, it was supposed to try each stage up to three times before declaring it a failure, logging each iteration, and then send email to the admins and return error codes up the stack. This week, the ruling came down that there would be no re-tries and the first FATAL error would send an email and then pass error codes up the stack and let main() exit. The app does everything from read and parse config files, read from SQLServer, make hundreds of calls to SOAP Windows Services, translate all retrieved data into many HL7 files, open a socket, and transmit the HL7s by TCP/IP. So there are a LOT of possible exceptions I would have to catch all through the code. Instead of a mare's nest of different catch blocks, I commonly only catch ones of type Exception and concatenate e.GetType().ToString() in the message.

The problem comes if anything in the module that constructs the message and invokes the email sending code fails or throws an exception. Obviously, I can't email about the failure of the email class, so, in addition to logging it (I log all warnings and errors anyway + debug and trace messages during testing), I display a console message about the failure and give the option of displaying a stack trace to the admin who finds the console msg. If I throw an exception from this deep, it is going to be caught and will have to be rethrown in each succeeding layer. Obvious perils can emerge here, including the fact that upper catch blocks can retrigger the email method, creating an endless loop. One solution would be to create a custom exception and test for that first in any try/catch block, merely rethrowing it up another level until it reaches Main(), which will return an error flag to int Main() & terminate with a return(errmsg). If I handle any failure in the email class by simply logging it, displaying the console message and then calling Environment.Exit(errcode), the refactoring would be much easier and won't mean touching a dozen different classes and their methods.

I was just wondering if .NET would clean up everything properly if I exited from some point other than main().

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

Beartooth Bronsky9y ago
Haha. I should have said I started C 37 years ago, added C++ 5 years later, and added Java in 1997 when it first became commercially stable. I also used 80x86 assembler during the PC DOS years. Before that, I did COBOL, BAL, and RPG II, with a bit of FORTRAN and EDL. It only SEEMS sometimes like I've been doing this for 89 years instead of 42.
I have continued to use C/C++ (an extension of C and a "better" C if you don't want to dance as much on the razor's edge ;) ) and Java regularly, often mixing them on the same projects, with plain old C still my favorite for its ability to go to such a low level and, under DOS, bypass both DOS and BIOS levels for efficiency. I have done a lot of digital video and financial algorithmic trading and datamining work that contains modules that Java is just not flexible enough to handle, so separate services are often done in different languages as needed.
The reason this came up was how to terminate if the sendmail method throws an exception. Originally, it was supposed to try each stage up to three times before declaring it a failure, logging each iteration, and then send email to the admins and return error codes up the stack. This week, the ruling came down that there would be no re-tries and the first FATAL error would send an email and then pass error codes up the stack and let main() exit. The app does everything from read and parse config files, read from SQLServer, make hundreds of calls to SOAP Windows Services, translate all retrieved data into many HL7 files, open a socket, and transmit the HL7s by TCP/IP. So there are a LOT of possible exceptions I would have to catch all through the code. Instead of a mare's nest of different catch blocks, I commonly only catch ones of type Exception and concatenate e.GetType().ToString() in the message.

The problem comes if anything in the module that constructs the message and invokes the email sending code fails or throws an exception. Obviously, I can't email about the failure of the email class, so, in addition to logging it (I log all warnings and errors anyway + debug and trace messages during testing), I display a console message about the failure and give the option of displaying a stack trace to the admin who finds the console msg. If I throw an exception from this deep, it is going to be caught and will have to be rethrown in each succeeding layer. Obvious perils can emerge here, including the fact that upper catch blocks can retrigger the email method, creating an endless loop. One solution would be to create a custom exception and test for that first in any try/catch block, merely rethrowing it up another level until it reaches Main(), which will return an error flag to int Main() & terminate with a return(errmsg). If I handle any failure in the email class by simply logging it, displaying the console message and then calling Environment.Exit(errcode), the refactoring would be much easier and won't mean touching a dozen different classes and their methods.

I was just wondering if .NET would clean up everything properly if I exited from some point other than main().
0
Nilesh Shah9y ago
All your experience of 37 years in C, 32 in C++, and 20 in Java amounts to 89 years in total. I hope you code in C# for another 50 years. :) :D

Jokes apart,

I would always trap and log the exception at hightest level of code, and make sure the exception raises some kind of alert, because it is a console app meant to be running in background and no one will notice it if it stops working.

You can throw the exception from lower levels of code and write some exception mechanisam in the highest calling method.

using exit will always terminate your code at that line only without giving you a chance to log exception.
0