Graceful handling of non-ICE exceptions #15139
Labels
annoys users 😢
medium effort
Default level of effort
medium impact
Default level of impact
must have
Something we consider an essential part of Solidity 1.0.
Abstract
Currently exceptions such as
UnimplementedFeatureError
,CodeGenerationError
,StackTooDeepError
andCompilerError
are reported as internal compiler errors, i.e. by completely interrupting what the compiler is doing and printing out diagnostic information that's meant to help with tracking down a bug in the compiler. This behavior is appropriate for development assertions, which generally won't fail unless there is a bug, but not for errors that users will normally encounter when compiling their code.Motivation
The current behavior is very confusing to users as evidenced by the discussion thread in #12783.
There have been some limited attempts at improving this, for example we do catch
UnimplementedFeatureError
if it carries a source location. Unfortunately this is not nearly enough. ThesolUnimplementedAssert()
macro for raising such errors does not even allow attaching a location, so it is uncommon to have one, even when it is easy to obtain. E.g. in #14913 the obvious thing to do would be to point at the problematicrequire()
call. Instead the user gets diagnostic info pointing at a location in the compiler's source, which is useless in that context. In other cases, like #15001 (comment), this limitation leads to dropping otherwise useful tests.Specification
There are several things we should do to address this situation:
UnimplementedFeatureError
,CodeGenerationError
,StackTooDeepError
andCompilerError
should be caught and reported as proper compilation errors even if they do not have a location.solUnimplemented()
should allow including location.solUnimplementedAssert()
should be removed to avoid suggesting that it's an assertion likesolAssert()
. It's actually a validation.UnimplementedFeatureError
where available. There aren't that many of them and it will greatly improve user experience.util::Exception
and if not caught where we expect them, they should generally be treated as any other unexpected exception by the top-level handler.Backwards Compatibility
I don't think there are any backwards-compatibility concerns associated with this change. Currently these exceptions produce diagnostic output that is platform-dependent and we don't guarantee its stability in any way.
The text was updated successfully, but these errors were encountered: