Throwable class design

[Jonathan M Davis]

On Wednesday, January 30, 2013 08:32:47 rumbu wrote:
> 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.

Exceptions get rethrown all the time. Heck, that's what happens with finally, 
scope(failure), and scope(exit). It's what you do when you need to react to 
the fact that the exception was thrown (maybe even to the specific exception) 
but aren't going to handle it in that section of code.

Now, mutating the exception before rethrowing is another thing. I'd tend to 
think that that was bad practice, but I suppose that it could be useful upon 
occasion. In general though, if I wanted to add information, I'd wrap the 
caught exception in a new exception and throw that.

- Jonathan M Davis