A compiler usually has three parts, usually called front-, middle- and backend. Errors can usually only happen at the frontend (syntax errors, type checking) and rarely at the backend (no enough space for output). During the middle-end, the optimization, no errors can happen. However, the compiler is usually not perfect and might contain bugs. So for debugging purposes some error handling is helpful. Should we use different error handling mechanisms for internal and external errors? For performance reasons, we could remove the internal error handling for release builds.
Another problem is to distuingish between inside and outside. A library usually does some input checking, because the caller is considered "outside". To remove this overhead, the library could document some restrictions and leave it to the users, which usually does not end very well. For example, memcpy requires that src and dst must not overlap, but in reality this causes problems [0]. This only works, if the programmer who writes the caller has the possibility and skills to adapt the callee. In other words, there is no inside-outside difference for her.
Another problem is to distuingish between inside and outside. A library usually does some input checking, because the caller is considered "outside". To remove this overhead, the library could document some restrictions and leave it to the users, which usually does not end very well. For example, memcpy requires that src and dst must not overlap, but in reality this causes problems [0]. This only works, if the programmer who writes the caller has the possibility and skills to adapt the callee. In other words, there is no inside-outside difference for her.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38