BIND 10 trac1543, updated. 35b589adb440f744d15a077855f7882df5b9e8c9 [1543] Have catch on the same line as }
BIND 10 source code commits
bind10-changes at lists.isc.org
Mon Jan 30 15:20:08 UTC 2012
The branch, trac1543 has been updated
via 35b589adb440f744d15a077855f7882df5b9e8c9 (commit)
via 32f93f7158f1291d24960eedf199e6a5e9a9fc98 (commit)
from 6868aeaa6c5e5404a783c65dd6e7dad30a843305 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 35b589adb440f744d15a077855f7882df5b9e8c9
Author: Michal 'vorner' Vaner <michal.vaner at nic.cz>
Date: Mon Jan 30 16:18:54 2012 +0100
[1543] Have catch on the same line as }
As it is tightly coupled with the previous try statement.
commit 32f93f7158f1291d24960eedf199e6a5e9a9fc98
Author: Michal 'vorner' Vaner <michal.vaner at nic.cz>
Date: Mon Jan 30 16:15:45 2012 +0100
[1543] Don't identify with the server
The server is a separate entity from the developer's collective mind,
which, at last for the time being, is not considered sentient. Therefore
the word "we" is not appropriate and the server should be described in
third person.
-----------------------------------------------------------------------
Summary of changes:
src/lib/server_common/portconfig.cc | 12 ++++--------
src/lib/server_common/server_common_messages.mes | 10 +++++-----
2 files changed, 9 insertions(+), 13 deletions(-)
-----------------------------------------------------------------------
diff --git a/src/lib/server_common/portconfig.cc b/src/lib/server_common/portconfig.cc
index 62e291c..5c9a7fe 100644
--- a/src/lib/server_common/portconfig.cc
+++ b/src/lib/server_common/portconfig.cc
@@ -64,8 +64,7 @@ parseAddresses(isc::data::ConstElementPtr addresses,
}
result.push_back(AddressPair(addr->stringValue(),
port->intValue()));
- }
- catch (const TypeError&) { // Better error message
+ } catch (const TypeError&) { // Better error message
LOG_ERROR(logger, SRVCOMM_ADDRESS_TYPE).
arg(addrPair->str());
isc_throw(TypeError,
@@ -135,8 +134,7 @@ installListenAddresses(const AddressList& newAddresses,
}
setAddresses(service, newAddresses);
addressStore = newAddresses;
- }
- catch (const SocketRequestor::NonFatalSocketError& e) {
+ } catch (const SocketRequestor::NonFatalSocketError& e) {
/*
* If one of the addresses isn't set successfully, we will restore
* the old addresses, the behavior is that either all address are
@@ -164,15 +162,13 @@ installListenAddresses(const AddressList& newAddresses,
//Anyway the new configure has problem, we need to notify configure
//manager the new configure doesn't work
throw;
- }
- catch (const exception& e) {
+ } catch (const exception& e) {
// Any other kind of exception is fatal. It might mean we are in
// inconsistent state with the boss/socket creator, so we abort
// to make sure it doesn't last.
LOG_FATAL(logger, SRVCOMM_EXCEPTION_ALLOC).arg(e.what());
abort();
- }
- catch (...) {
+ } catch (...) {
// As the previous one, but we know even less info
LOG_FATAL(logger, SRVCOMM_UNKNOWN_EXCEPTION_ALLOC);
abort();
diff --git a/src/lib/server_common/server_common_messages.mes b/src/lib/server_common/server_common_messages.mes
index eb6362d..3b3090d 100644
--- a/src/lib/server_common/server_common_messages.mes
+++ b/src/lib/server_common/server_common_messages.mes
@@ -81,17 +81,17 @@ be hidden, as it has higher debug level.
% SRVCOMM_EXCEPTION_ALLOC exception when allocating a socket: %1
The process tried to allocate a socket using the socket creator, but an error
occurred. But it is not one of the errors we are sure are "safe". In this case
-it is unclear if the unsuccessful communication left us and the bind10 process
-in inconsistent state, so we're going to abort to prevent further problems in
-that area.
+it is unclear if the unsuccessful communication left the process and the bind10
+process in inconsistent state, so the process is going to abort to prevent
+further problems in that area.
This is probably a bug in the code, but it could be caused by other unusual
conditions (like insufficient memory, deleted socket file used for
communication).
% SRVCOMM_UNKNOWN_EXCEPTION_ALLOC unknown exception when allocating a socket
-The situation is the same as in the SRVCOMM_EXCEPTION_ALLOC case, but we don't
-know further details about the error, because it was signaled by throwing
+The situation is the same as in the SRVCOMM_EXCEPTION_ALLOC case, but further
+details about the error are unknown, because it was signaled by throwing
something not being an exception. This is definitely a bug.
% SRVCOMM_KEYS_DEINIT deinitializing TSIG keyring
More information about the bind10-changes
mailing list