<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 29, 2014 at 8:13 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">My entire point is, it doesn't matter what is expected or what is treated as "correct." what matters is where the input CAME from. To a library function, it has no idea. There is no extra type info saying "this parameter comes from user input."</blockquote><div><br></div><div>From the method's view, parameters passed in are user input.  Full stop.</div><div><br></div><div>One thing that seems to be talked around a bit here is the separation/encapsulation of things.  It is perfectly fine, and expected, for a library method to throw exceptions on bad input to the method - even if this input turns out to be a programming bug elsewhere.  From the standpoint of the method, it does not know (and does not care) where the thing ultimately came from - all it knows is that it is input here, and it is wrong.</div><div><br></div><div>If you call a method with bad input, and fail to catch the resulting exception, then _that_ is a bug, not the method throwing.  It may be perfectly recoverable to ignore/retry/whatever, or it may be a symptom of something that should abort the program.  But the method throwing does not know or care.</div><div><br></div><div> </div></div></div></div>