On Thursday, 1 June 2017 at 17:03:52 UTC, Ali Çehreli wrote:
On 06/01/2017 08:41 AM, Vasileios Anagnostopoulos wrote:
//If I do not know
void haveToCommunicateWithAli() {
sendEmailToAli();
}
//can blow-up after code has shipped
//and have no chance to recover
What shall I do in this case? Thank you in advance.
Vasileios
(Sorry if I go to too basic levels here.) I used to think that
an unhandled exception was a program crash. It's not. It's a
good thing that a program aborts due to an uhandled exception.
What happened is that it could not achieve it's task. There was
nothing else it could do, so it terminated. (For example, it
did not continue with unhealthy radiation levels on the
patient.)
Although an abort may be the safest thing to do in many cases,
it's not user-friendly. So, you catch the exception at the
highest level that it matters or that you can do something
about it. For example, you can catch the exception in main(),
report a friendly error, and return 1.
Or, you may be in a loop, preparing letters, you catch around
that code and either report an error or perhaps grab more
stamps and repeat the last operation.
So the answer is, don't catch exceptions any lower than it
really matters, which could be as high as the main() function.
Ali
But still I believe that @nothrow should be mandatory if there is
no possibility for a function to throw something. I understand
that in the DLL/LIB level this is not possible. However, at least
in the .di level it should be there.
And if you want my two cents, after reading a lot I came to the
"personal" conclusion that Exception objects are wrong. For me it
is enough to have something like
void A() {
raise;
}
void B() {
raise;
}
void C() {
raise;
}
void D () nothrow { //the compiler inferred from body that D
cannever throw
scope(failure) {
writeln("The end of the world");
exit(1);
}
try {
A();
} else try {
B();
} else {
C();
}
}
