Augment Exception implementations with additional data

[Blacksmoke16]

Thoughts on adding additional ivars to select exception types to expose additional information about the exception? For example, TypeCastError, only exposes the exception message, such as cast from Nil to String failed. However, there isn't a way to know typed failed to cast to what type.

It would be nice to be able to do something like:

require "json"
 
def convert(type : String.class, data)
  data.as_s
rescue ex : TypeCastError
  raise "Expected #{type} but got #{ex.from_type}"
end
 
convert String, JSON.parse("null")

Currently the only way to do this is to parse the type from the message. However, this is assuming the specific instance of TypeCastError has that data in the message in the first place.

Granted, not all exceptions would need this. I could see like IndexError or KeyError including a reference to the index/key that caused the exception.

[RX14]

File and Socket errors should carry a reference to which IO::FileDescriptor/Socket instance the error occurred on, too.

[Blacksmoke16]

Alright cool. Here's what I'm thinking:

• IndexError
  • #index - Index that caused the error
• KeyError
  • #key - Key that caused the error
• TypeCastError
  • #from_type - Actual type of the value being casted
  • #to_type - Expected type after casting
• IO::Error
  • #io - The related IO object (could be a file/normal io depending on the context)

How's that sound?

Some questions:

• This ofc would be a breaking change for exception types
• How to handle typing; mainly for KeyError, TypeCastError, and IndexError
  • Generics?

[asterite]

We could provide those things as strings. Why do you need the type? Those exceptions signal bugs in the code, they are not meant to be rescued.

[waj]

What’s the use case? In your example you just re-raised another, less specific, exception.

About the IO keep in mind that many times the one that raises the exception is wrapped around other layers so it’s not easy to use it properly during error handling. And handling and re-raising everywhere is just too costly. I wonder why I didn’t see such property in analogous exceptions of other languages.

[RX14]

Interestingly, Go's errors.Is and errors.As are neat ways to "find" an exception in an exception which has a cause. It'd be possible to provide something similar in crystal for extracting an IO::Error from any exception which wraps it.

[Blacksmoke16]

We could provide those things as strings.

I'd probably be okay with this.

What’s the use case? In your example you just re-raised another, less specific, exception.

I could see a use for logging, as it would allow running aggregations against the values versus just the string.

Of course, that was just an example. In reality I would be using it to pull out the actual type provided to reraise another exception with context that the original exception doesn't know about. Something like:

ParseException.new self.format, "Could not parse #{type} from #{data} (#{ex.from_type})."

[didactic-drunk]

We could provide those things as strings. Why do you need the type? Those exceptions signal bugs in the code, they are not meant to be rescued.

I was going to keep them as ivars to avoid unnecessary String creation. Not every exception is printed.

class IndexError
  # Are all of start/count/size optional? *shrug*
  def initialize(message` : String? = nil, cause : Exception? = nil, *, @start, @count = nil, @size)
    super message, cause
  end

  # Modify `inspect` to print the additional variables.
  # Maybe this should be the default?

[straight-shoota]

I follow the general motivation for this. There is however always a struggle between expressiveness and performance/complexity implications.

Adding additional properties to error types does not have a big impact by itself. But that does not help too much, except when the error and its metadata is interpreted by an error handling mechanism.
Most likely, the motivation is based on this metadata showing up in the error message. That means either an additional string allocation for every error instance, or building the message on demand. Both approaches have their own set of implications and so far we've been trying to mostly avoid that. But I think we can try to find feasible solutions to improve this.

A big factor for deciding if and what kind of metadata to attach to an error type is the nature of such an error.

Error types that are more internally focused and typically signal a bug, don't require additional data. TypeCastError would be a prototypical example of that. When a type cast fails, it means there is a bug in the code. Details may be useful for debugging, but not to the affected user.

Error types that represent an error state that can happen in normal program execution and are intended to be shown to the user, benefit a lot from additional error information. An example for this would be Socket::ConnectError which can contain information about the address that was being connected to (this is currently only contained in the message, though, and not accessible as an individual field).

I suppose, IndexError and KeyError often belong to the second category. Enhancing them with information about the lookup target could be appropriate.

We need to look at individual error types about if and what kind of data they could expose.
And we need to determine good strategies to incorporate that additional information into error messages.

[didactic-drunk]

Most likely, the motivation is based on this metadata showing up in the error message. That means either an additional string allocation for every error instance, or building the message on demand.

A big factor for deciding if and what kind of metadata to attach to an error type is the nature of such an error.

You split error types in to 2 categories. An error type can be both categories (or a 3rd) depending on it's use.

Here are 2 real examples I run in to all the time and have my local crystal modified to show me the index.

ary[x]
#  Unhandled error.  I **require** the a printed index to debug the program.

begin
  ary[x]
rescue IndexError
  # Expected exception.  Nothing printed.  Additional strings only add overhead.
end

Neither of these cases requires exception handling of the additional data. The additional data is only for debugging if printed.
Again, strings were avoided to reduce overhead for the more common case of handled exceptions because crash is at most once per program (or possibly once per fiber/request).

There seems to be an assumption that additional data is only for programs to access and strings are only for info/debugging.
I don't think those unwritten rules should apply specifically for performance reasons and #10746 was written with performance in mind using additional variables only for debugging, specifically to avoid string allocations.