On Wednesday, 30 January 2013 at 07:01:56 UTC, H. S. Teoh wrote:
Not true. I use this idiom a lot: a lower level function throws
an error
message (e.g., integer format error), and a catch-block halfway
up the
call-chain modifies .msg to include contextual information
(e.g.,
filename, line number) and rethrows the exception, so that at
the top
level the error message contains both context information and
the
low-level error message.
T
I thought exceptions are meant to be catched, not rethrown.
If you are the developper of an end user solution, you'll catch
the exception and you will display a message some way with the
details that you need, or, better, you will silently drop the
exception taking the necessary actions to resolve the cause.
Throwing exceptions in the user's face is not so friendly.
If you are a library developper, you'll catch the exception and
you will rethrow *another* exception wrapping the original
exception in the next field through the constructor. Target
developpers of your library have no interest in your detailed
message, but in the *type* of the exception thrown. Their program
flow cannot interpret messages.
