<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 29, 2014 at 11:58 AM, Steven Schveighoffer via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/29/14 2:43 PM, Jeremy Powers via Digitalmars-d wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d<br></span><span class="">
<<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a> <mailto:<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@<u></u>puremagic.com</a>>> wrote:<br>
<br>
    My entire point is, it doesn't matter what is expected or what is<br>
    treated as "correct." what matters is where the input CAME from. To<br>
    a library function, it has no idea. There is no extra type info<br>
    saying "this parameter comes from user input."<br>
<br>
<br></span><span class="">
 From the method's view, parameters passed in are user input.  Full stop.<br>
</span></blockquote>
<br>
This is missing the point of an exception. An uncaught exception is an error which crashes the program. If you catch the exception, you can handle it, but if you don't expect it, then it's a bug. Any uncaught exceptions are BY DEFINITION programming errors.</blockquote><div><br></div><div>I agree (except the bit about missing the point).  The point I wanted to make was that encapsulation means what is a fatal error to one part of a program may be easily handled by the containing part.  Just because an exception is thrown somewhere does not mean the program is broken - it is the failure to handle the exception (explicit or inadvertent) that indicates an error.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What is being discussed here is removing the stack trace and printout when an exception is thrown.<br>....</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure, but it doesn't happen. Just like people do not check return values from syscalls.<br>
<br>
The benefit of the exception printing is at least you get a trace of where things went wrong when you didn't expect them to. Ignoring a call's return value doesn't give any notion something is wrong until much later.<br>
<br>
-Steve<br>
</blockquote></div><br></div><div class="gmail_extra">I absolutely do not want a removal of stack trace information.  If an uncaught exception bubbles up and terminates the program, this is a bug and I sure as hell want to know as much about it as possible.  If having such information presented to the end user is unacceptable, then wrap and spew something better.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ignoring an error return value is like ignoring an exception - bad news, and indicative of a broken program.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>