CODEWITHSUNDEEP
scalacompiler-errorswarnings
Owen
Owen

Reputation: 39356

Can I force scala to error on an inexhaustive match?

An inexhaustive match such as 

def foo[A](t: Seq[A]) = t match {
    Seq(x) => x
}

is often (not always, but usually) a mistake on my part that will crash at runtime. Scala warns, but in an incremental build, the file might already be compiled so I will miss the warning.

Is there a way, either globally or locally, perhaps by an annotation, to force scala to turn the warning into an error?

Upvotes: 4

Views: 989

Answers (2)

som-snytt
som-snytt

Reputation: 39577

It's possible to supply a custom reporter that arbitrarily reports warnings as errors (or conversely), but the API is currently string-based, so it would filter on string messages and not typed warnings.

There is no built-in way to fail on particular warnings, but -Xlint -Xfatal-warnings is the usual way to escalate warnings.

Warning suppression has been requested, but considered dangerous. With fatal warnings, the requirement would be to suppress the warnings that are considered benign.

If you have a residual deprecation, it's possible to suppress the warning (which would fail under -Xfatal-warnings) by invoking it from a deprecated method; if that method is local, it won't generate a warning.

scala> @deprecated("","") def f = 8
f: Int

scala> f
<console>:9: warning: method f is deprecated: 
              f
              ^
scala> object A {
     | def a = {
     | @deprecated("","") def _f = f
     | _f
     | }}
defined object A

scala> A.a
res1: Int = 8

The local deprecation trick was itself deprecated, but you can still use a forwarding companion:

scala> @deprecated("","") def f = 8
f: Int

scala> f
warning: there was one deprecation warning; re-run with -deprecation for details
res0: Int = 8

scala> @deprecated("","") class C { def g = f }; object C extends C
defined class C
defined object C

scala> C.g
res1: Int = 8

Upvotes: 4

Richard Sitze
Richard Sitze

Reputation: 8463

Consider asking questions about your build process.

  1. You should be doing a full, clean build (not incremental) and running unit tests immediately prior to code commit/check-in. This to avoid (potential, remaining) bugs in SBT or your build process. You are, of course, expected to monitor the results for errors and warnings.

  2. Are you, or perhaps should you be, doing Continuous Integration (automatic, scheduled build/tests)? During such you may have, or introduce, some control over how warnings are addressed (ignored or trigger build failure/warning).

  3. I don't see way to do this from the scalac command line. If all other approaches don't meet your needs then consider as a last resort, and then only if appropriate to your build tooling: create a wrapper script for scalac, also named scalac that:

    • invokes the true scalac
    • monitors output: return error when the particular error is printed, and perhaps delete the target class file [captured from error statement] to further force the issue.

Upvotes: 0

Related Questions