Why wouldn't you declare main() using a function-try-block?

Question

There are a few SO posts about whether or not declaring main() using function-try-block syntax is valid syntax , and the general consensus seems to be that it's perfectly valid. This left me wondering... is there any reason (performance, style, thread synchronization, multithreading) why one wouldn't use this syntax for main() as a general rule to catch any unhandled exceptions anywhere more gracefully?

Obviously, ideally there won't be unhandled exceptions, but they happen and I think it'd be nice to provide something more informative than the OS-specific default handler. For example, in my case, I'd like to provide a support email address to the user so they can report the crash and have my program submit a log to my cloud-based crash log.

Answer 1

For example, in my case, I'd like to provide a support email address to the user

Well, how are you going to do that in a server with no user-facing interface?

Actually, how are you going to do that even in a process with user-facing components, if you have no way to tell in the catch block what state they're in?

And, for those processes where you can't show the user anything useful (or don't have any concept of a "user" in the first place), what would you do in your catch block that would be better than the default terminate ?

As for

... more informative than the OS-specific default handler ...

many OS' default behaviour will be to save a complete snapshot of the process execution state, at the point the un-handled exception is thrown, to a file for debugging. As the developer, I can't think of many default behaviours that would be more informative.

Admittedly I'd prefer something more polished as the end user of a desktop app, but that's a pretty small subset of C++ programs.

Answer 2

If you happened to have a variable that you want to access in your catch block, you would need the curly braces to provide visibility. But even that could be handled with nested try/catch...

Answer 3

If you catch the (otherwise) uncaught object, you won't be able to figure out how the execution reached the throw by inspecting the stack trace, because when exception handler is executed, the stack has already been unwound.

If you let the unexpected exception to be uncaught, you may be able to inspect the stack trace in the terminate handler - this is not guaranteed by the standard, but that's not a big deal since there is no standard way to inspect the stack trace either (in C++). You can either use platform specific API within the program, or an external debugger for the inspection.

So for example in your case, the advantage of not catching the exception would be that you can attach a stack trace to the log entry that you intend to submit.

Also, there are cases where an exception can not be handled by a catch block. For example, when you throw from a destructor that is being executed as a result of throwing an exception. So, to handle these "uncatchable" exceptions, you need a terminate handler anyway, so there is little advantage in duplicating the functionality in the case of uncaught exceptions.

---

As for the syntax that you use to catch the exception, there is no difference. The case where the function try block is different is a constructor, where it allows catching exceptions thrown by sub object constructors.

Answer 4

You can easily convert

int main() try {
   // The real code of main
}
catch (...)
{
}

to

int realMain()
{
   // The real code of main
}

int main()
{
   try
   {
      return realMain();
   }
   catch ( ... )
   {
   }
}

without losing functionality/behavior.

I am going to guess that whether you use the first version or the second version is a matter of coding practices of a team. From a compiler and run time standpoint, I don't see any semantic difference.

Answer 5

why one wouldn't use this syntax for main() as a general rule to catch any unhandled exceptions anywhere more gracefully?

1. compatibility with C.
2. Sometimes there is no way to handle unhandled exceptions more gracefully.

Obviously, ideally there won't be unhandled exceptions, but they happen and I think it'd be nice to provide something more informative than the OS-specific default handler. For example, in my case, I'd like to provide a support email address to the user so they can report the crash and have my program submit a log to my cloud-based crash log.

If unexpected exception happens you can not be sure that it is possible to handle it correctly. What are you going to do if there is a network error exception in your example. And trying to send e-mail causes another exception? There can be other errors when you can not be sure that your data is not corrupted and you can not be sure that your program can run correctly after this error. So if you don't know what error happened it is better to allow your program to crash. You can implement another "watcher" service that checks if process is running and if it has been crashed it can send e-mail to your users with the logs and core dumps.