Exceptions and data safety

[kpamnany]

#51673 opens a discussion on exceptions, but doesn't really seem to go anywhere.

We have a different angle to consider, thus I'm opening a separate issue: it is not unusual for packages to throw exceptions and embed user-provided data in the exception message. For security and privacy reasons, we do not want to log user-provided data so we cannot generally log exception messages which is quite annoying when you're trying to figure out why an exception was thrown.

It is impractical to verify the safety of the contents of exceptions thrown from all packages, but it is practical to do so for Base. Unfortunately, even if we did this verification, there's no easy way to disambiguate an exception thrown from Base from an exception thrown from a package... unless they are different exceptions.

To that end, we'd like to introduce an InternalException and replace error() calls in Base with something that raises one of these. We could potentially go further and introduce a type hierarchy of internal exceptions that are only raised in Base, but this might get complicated. We could then treat all InternalExceptions as "safe to log".

Thoughts?

[KristofferC]

If the question is only if the throw call originated from within Base then perhaps some stacktrace inspection could be used? Doing a whole separate exception class just to see if they come from Base doesn't feel that great. It also feels kind of brittle because objects from user code could easily enter Base and perhaps get wrapped in some exception that Base ends up throwing.

[nickrobinson251]

@kpamnany as i understand it, you were not meaning this to apply to Base, but only to "the runtime and the compiler" -- e.g. it wouldn't change the error(...) thrown by PermutedDimsArray, but it would change the error(...) thrown by schedule -- is that right?

[kpamnany]

There is no interesting/useful content embedded in the ErrorException thrown by schedule (see here for example); this is true of quite a few of the ErrorExceptions thrown by the runtime -- the message has nothing embedded in it, so the line number of the error call (in the stack trace) is sufficient. But there are exceptions. This came up because we wanted to see the message in the ErrorException thrown by Base.compilecache. We verified that it was safe and special-cased it, but felt that it would be useful to have some broad assurances about user data safety.

[kpamnany]

Kristoffer: stack trace inspection seems even more brittle.

This is not really about exceptions from Base; the idea was to start with Base. User data protection is something many commercial applications would be concerned with, especially in the cloud where logging is a primary observability tool. Having an exception class that assures that no user data is exposed is one way forward.

[KristofferC]

User data protection is something many commercial applications would be concerned with, especially in the cloud where logging is a primary observability tool.

Are there any good prior work in other programming languages that some inspiration can be taken from?