question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Show real type names in error messages

See original GitHub issue

In #4323 I was concerned about writing incorrect names for types in error messages.

Writing Expr’ in the error seems a (separate?) bug:

15 |     case (IExpr(i1), IExpr(i2)) => IExpr(i1 + i2)
   |                                    ^^^^^^^^^^^^^^
   |                                    found:    Expr.IExpr
   |                                    required: Expr'[T]
   |                                    
   |                                    where:    Expr  is a object
   |                                              Expr' is a trait

because it’s false that “Expr' is a trait”. A bit better would be:

   |                                    where:    Expr  refers to object Expr
   |                                              Expr' refers to trait Expr

But even better would be to have a clearer syntax for these “footnotes”, something where the annotation is more clearly separate from the Scala syntax. For instance, if we use @ (which is reserved and can’t be used in types, I think):

   |                                    where:    Expr@1  refers to object Expr
   |                                              Expr@2 refers to trait Expr

Issue Analytics

  • State:open
  • Created 5 years ago
  • Reactions:2
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
Blaisorbladecommented, Apr 21, 2018

“Expr1 is an object in package foo.bla.baz”. I just dislike using import renaming to express this.

Import renaming also seems unconvincing, but again, we shouldn’t write that Expr1 isn’t an object, because that object is called Expr. I’d say that Expr1 isn’t an object.

Expr@1 is almost valid Scala syntax too, and having to read error message “as interpreted under a given set of renaming” is likely to endlessly confuse beginners. My preference would be to use unicode subscripts: Expr1, Expr2, we could also differentiate them using colors.

I agree with Unicode subscripts are better if we can rely on Unicode, since they’re not allowed in Scala.

Which we probably often can. Otherwise, Expr@1 was the best idea I had within ASCII after skimming https://stackoverflow.com/a/7657692, but I’m not sure it’s much better.

0reactions
smartercommented, Apr 20, 2018

We can also have a longer description such as “Expr1 is an object in package foo.bla.baz”. I just dislike using import renaming to express this. Note that import renaming is not enough anyway because some types do not have a stable path, e.g.:

class Foo {
  def meth = {
    class Expr
    def expr(e: Expr) = {}

    def bla = {
      class Expr
      expr(new Expr)
    }
  }
}

Here’s the error Dotty outputs currently:

8 |      expr(new Expr)
  |               ^^^^
  |               found:    Expr
  |               required: Expr'
  |               
  |               where:    Expr  is a class in method bla
  |                         Expr' is a class in method meth
Read more comments on GitHub >

github_iconTop Results From Across the Web

How to display Sequelize validation error messages in ...
I tried your same validation on my local project on firstName field and I could get sequelize error like this console.log('err.name', ...
Read more >
9 Error messages | The tidyverse style guide
9 Error messages. An error message should start with a general statement of the problem then give a concise description of what went...
Read more >
Video: Input and error messages - Microsoft Support
On the Input Message tab, check the box next to Show input message when cell is selected. Type a Title if you want....
Read more >
A story told by Type Errors - Dmitrii Kovanikov
In this blog post I'm going to show that using custom type errors is a simple task. I will present a lot of...
Read more >
Custom error messages in JSON Schemas for Ajv validator
Property names can be used in error messages with the relative JSON-pointer (e.g. 0# ). Example: const schema = { type: "object", ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found