/ 
Data-Show-0.004001
River stage one • 1 direct dependent • 1 total dependent
/ Data::Show

NAME

Data::Show - Dump data structures with name and point-of-origin information

VERSION

This document describes Data::Show version 0.004001

SYNOPSIS

use Data::Show;

show %foo;
show @bar;
show (
    @bar,
    $baz,
);
show $baz;
show $ref;
show @bar[do{1..2;}];
show 2*3;
show 'a+b';
show 100 * sqrt length $baz;
show $foo{q[;{{{]};

DESCRIPTION

This module provides a simple wrapper around various data-dumping modules.

A call to show() data-dumps its arguments, prefaced by a context string that reports the arguments and the file and line from which show() was called.

For example, the code in the SYNOPSIS might produce something like the following:

### try_SYNOPSIS.pl
### 16:     show %foo;
>>>
>>> ( f => 1, o => 2 )

### 17:     show @bar;
>>>
>>> qw( 3 . 1 4 1 5 )

### 18:     show (
### 19:         @bar,
### 20:         $baz,
### 21:     );
>>>
>>> (3, ".", 1, 4, 1, 5, "baz value")

### 22:     show $baz;
>>>
>>> "baz value"

### 23:     show $ref;
>>>
>>> {
>>>     a => [1, 2, 3],
>>>     h => { x => 1, y => 2, z => 3 },
>>>     s => \"scalar",
>>> }

### 24:     show @bar[do{1..2;}];
>>>
>>> qw( . 1 )

### 25:     show 2*3;
>>>
>>> 6

### 26:     show 'a+b';
>>>
>>> "a+b"

### 27:     show 100 * sqrt length $baz;
>>>
>>> 300

### 28:     show $foo{q[;{{{]};
>>>
>>> undef

If you have Term::ANSIColor installed, you get an even cleaner dump with the context, source code, and dumped values distinguished in distinct, accessible, and configurable colours.

INTERFACE

use Data::Show;

Loading the module without arguments exports a single show() subroutine that dumps its argument(s) to STDERR, using either the Data::Pretty module, or else Data::Dump, or else Data::Dumper, or else Dumpvalue (whichever is first available, in that order - see "Fallbacks").

The show() subroutine is the only subroutine provided by the module. It is always exported.

show() can be called with any number of arguments and data-dumps them all with a suitable header indicating the arguments, and the file and line from which show() was called.

show() returns its own argument(s), which allows you to place it in the middle of a larger expression to check an intermediate value (see "Inlined dumps").

Changing the module used to dump data

use Data::Show with => 'MODULE::NAME';

If you pass a 'with' argument when loading the module, it exports the single show() subroutine that dumps its argument(s) to STDERR using the specified dumper plugin. For example:

use Data::Show  with => 'Data::Printer';

use Data::Show  with => 'Data::Dmp';

use Data::Show  with => 'Legacy';

use Data::Show  with => 'My::Own::Dumper';

If the requested module is not available (i.e. can't be loaded), then a fallback (see "Fallbacks") is used instead.

See "Plugins" for details of how to specify any of the standard plugins, and how to create and name your own plugins.

Specifying a fallback dumper

use Data::Show fallback => 'MODULE::NAME';

You can specify a fallback plugin to be used if the requested (or default) dumper plugin cannot be loaded. This fallback will be used any time the requested plugin cannot be located, or fails to load, or does not supply the necessary dumping methods. The specified fallback represents the starting point for the standard fallback process. See "Fallbacks".

Changing the destination to which data is dumped

use Data::Show to => TARGET_SPECIFIER;

Loading the module with a 'to' argument exports the single show() subroutine that dumps its argument(s) to the specified target (rather than to STDERR). The specified target can be a filename, an already-opened filehandle, or a variable reference. For example:

use Data::Show  to => \*STDOUT;

use Data::Show  to => \$capture_variable;

use Data::Show  to => 'some_file_name';

Exporting show() under another name...

use Data::Show as => 'explicate';

The module always exports a single show() subroutine, but show() is an extremely generic name, which could easily already be used in some other way in the code you are debugging.

So the module can export show() under another name, by loading it with the 'as' option, passing the desired alternative name as a string.

Specifying the output width

use Data::Show termwidth => 78;

Loading the module with a 'termwidth' argument sets the maximum width value that will be passed to plugins when they are asked to dump data. The default maximum is 78 columns, but using this option that maximum can be reset to any desired positive integer value.

Note that plugins are always free to disregard the maximum terminal width they are passed, and will often do so in the interest of showing the dumped data fully. However, the built-in plugins that support grid output will always constrain their output grids to the requested terminal width.

Silencing warnings

The module produces a number of compile-time warnings , most of which can be silenced, by loading it with the 'warnings' option, as follows:

use Data::Show warnings  => 'off';

Note that if the option is specified with any value except 'off', then warnings will remain enabled. Specifically, passing a false value for 'warnings' does not turn off warnings. If you need to control warnings via a boolean value (say in the variable $ENV{WARNINGS}), use something like:

use Data::Show warnings => ($ENV{WARNINGS} ? 'on' : 'off');

Requesting grid output

use Data::Show grid  => 'on';   # Or any other true value except 'off'

Normally, the context and data information produced as the output of the show() subroutine are distinguished by prefixes or by colour/styling. However, you can also request that the context and data are placed in a grid, to more clearly distinguish the module's output from the program's regular output.

When requested, the grid is generated automatically, using either ASCII punctuation characters:

 _______________________________
|20:   show (                   |
|21:      \@bar,                |
|22:       $baz,                |
|23:   );                       |
|-------------------------------|
| ( ['b', 'a', 'r'], 'baz' )    |
|_______________________________|

...or (if the the module can determine that the terminal supports UTF8 output), using Unicode box-drawing elements:

┏━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃19│   show (                   ┃
┃20│      \@bar,                ┃
┃21│       $baz,                ┃
┃22│   );                       ┃
┠──┴────────────────────────────┨
┃ ( ['b', 'a', 'r'], 'baz' )    ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

The choice to use Unicode is made by examining the $ENV{LC_ALL}, $ENV{LC_TYPE}, and $ENV{LANG} environment variables. If any of them are set to a value that includes the strings 'utf-8' or 'UTF-8', then the terminal is assumed to be Unicode capable.

You can also explicitly turn grid output off (if, for example, it was turned on by default in your .datashow file):

use Data::Show grid  => 'off';

Specifying the output style

The module allows you to configure every aspect of the styling of its output (including whether or not it the output has any styling). Normally, the module determines automatically whether colour output is appropriate or possible, by checking for the availability of the Term::ANSIColor module. If that module can be loaded, it is used to style the output; if not, the output is unstyled.

However, you can explicitly disable output styling (regardless of the availability of Term::ANSIColor) by passing the appropriate 'style' option when the module is loaded:

use Data::Show style => 'off';

You can also turn off styling of just the data dump (leaving the context information styled) with:

use Data::Show style => 'context';

If you wish to explicitly request the default automatic styling (for example, to override an option specified in the .datashow file), you can do so with:

use Data::Show style => 'auto';

In addition to controlling whether styling is used at all, you can also specify exactly what styling is used for each component of the output, using the various '...style' options. Each option takes a string value containing either two Term::ANSIColor style specifications, separated by a comma (the first of which is used for terminals with dark backgrounds, and the second of which is used for terminals with light backgrounds):

use Data::Show
#   COMPONENT    FOR DARK BG     FOR LIGHT BG
#   =========    ===========     ============
    datastyle => 'bold white ,   bold black',
    showstyle =>  'bold cyan ,    bold blue',
    codestyle =>       'cyan ,         blue',
    filestyle =>       'blue ,          red',
    linestyle =>       'blue ,          red',
    gridstyle =>       'blue ,          red';

Alternatively any of these options can be specified with a single string containing only one Term::ANSIColor style specification (which is then used for both light- and dark-background terminals):

use Data::Show
#   COMPONENT    FOR ALL BGS
#   =========    ===========
    datastyle => 'bold red',
    showstyle => 'bold green',
    codestyle => 'green',
    filestyle => 'cyan',
    linestyle => 'cyan',
    gridstyle => 'blue';

You can specify as many or as few of these options as you wish, and mix any number of single- and light/dark values in a single call.

The effect of each option is as follows:

datastyle

The style in which the dumped data is output (default: 'bold white, bold black')

showstyle

The style in which the show statement itself is output (and highlighted) as part of the context information (default: 'bold bright_cyan, bold bright_blue')

codestyle

The style in which any other ambient source code is output (and typically de-emphasized) as part of the context information (default: 'cyan, blue')

filestyle

The style in which filenames are output as part of the context information (default: 'blue, red')

linestyle

The style in which line numbers are output as part of the context information (default: 'blue, red')

gridstyle

The style in which gridlines are drawn (default: 'blue, red')

Lexically disabling show()

During a debugging session it can be useful to turn off the data dumping behaviour of the show() subroutine, without having to comment out, or remove, every call to it throughout the source code.

If you load the module with no instead of use:

no Data::Show;

...then the dumping behaviour of show() is disabled within the rest of the lexical scope. So, if you anticipate needing to continue debugging at a later stage, you can set up a series of calls to show() and then "turn them off" without actually having to remove them immediately.

Of course, those calls still impose a slight overhead on your code so you should still actually remove the calls to show() from your source, once you are confident that you have genuinely finished debugging it.

Plugins

Because most dumper modules have distinct and incompatible interfaces, the Data::Show module uses object-oriented wrapper classes to convert each dumper module into a compatible API. This also makes it easy to integrate other modules you may wish to use as dumpers for Data::Show.

Wrapper classes are automatically generated for the following core or CPAN dumper modules:

Data::Dmp
Data::Dump
Data::Dump::Compact
Data::Dumper
Data::Dumper::Color
Data::Dumper::Concise
Data::Dumper::Table
Data::Pretty
Data::Printer
Data::TreeDumper
Dumpvalue
YAML
YAML::PP
YAML::Tiny
YAML::Tiny::Color

But you can also write your own plugin wrapper classes to allow Data::Show to make use of other dumper modules.

Each wrapper class must be declared with a name beginning Data::Show::Plugin::, where the convention is that the rest of the wrapper's name is the name of the dumper module it's wrapping. For example:

Data::Show::Plugin::Data::Dumper
Data::Show::Plugin::Data::Dump
Data::Show::Plugin::YAML
Data::Show::Plugin::My::Own::Dumper

Each such wrapper class must provide two methods: stringify() and format(). Both methods should expect to be called on the class itself (i.e. as common methods), rather than on an actual object (i.e. not as instance methods).

The stringify() method expects a single argument: a data value or reference that is to be stringified. The stringify() method is expected to return a single string representing that data in some way.

For example:

# Create a plugin to allow Data::Show to dump using the Data::Dumper module...
package Data::Show::Plugin::Data::Dumper;

sub stringify ($class, $data) {
    use Data::Dumper 'Dumper';
    return Dumper($data) =~ s{ ; (\s*) \z }{$1}xr;
}

When creating plugin you can, of course, use the new Perl OO syntax instead:

class Data::Show::Plugin::Data::Printer;

method stringify ($data) {
    use Data::Printer;
    return np($data, colored=>1) . "\n";
}

The second method that a plugin must provide is format(). It is passed nine arguments:

$file          # The name of the file from which show() was called
$line          # The line at which show() was called
$pre_source    # Any source code on that line before the call to show()
$source,       # The source code of the call to show()
$post_source   # Any source code on the same line after the call to show()
$data          # The already-stringified data to be shown
$style         # A hash containing the various style configuration values
$termwidth     # The maximum terminal width nominated by the user

The format() method is expected to use this information to return a single formatted string (possibly including terminal escape codes) that will then be output as the result of the call to show().

For example:

class Data::Show::Plugin::Legacy;

method format ($class, $file, $line, $pre, $source, $post, $data, $style, $termwidth) {

    # Extract description of arglist from source...
    $source =~ s{\\A show \b \\s*}{}x;
    $source =~ s{\\s+}{ }gx;
    $source =~ s{\\A \\( (.*) \\) \\Z}{$1}x;

    # Trim filename and format context info and description...
    $file =~ s{.*[/\\\\]}{}xms;
    my $context = "[ '$file', line $line ]";

    # Insert title into header...
    my $header = '=' x $termwidth;
    substr($header, $TITLE_POS, length($source)+6) = "(  $source  )";
    substr($header, -(length($context)+$TITLE_POS), length($context)) = $context;

    # Indent data...
    $data =~ s{^}{    }gxms;

    # Assemble and send off...
    return "$header\\n\\n$data\\n\\n";
}

Note that, if you are generally happy with the output formatting that Data::Show provides by default, it is not necessary to write your own format() method when creating a new plugin; you can choose to simply inherit the default one:

class Data::Show::Plugin::My::Own::Dumper;

use Data::Show 'base';     # Inherit format() from Data::Show::Plugin

method stringify ($data) {
    use My::Own::Dumper;
    return My::Own::Dumper->new->dump($data);
}

...or, if you want legacy Data::Show formatting for your new plugin:

class Data::Show::Plugin::My::Own::Dumper::Legacy;

use Data::Show base => 'Data::Show::Plugin::Legacy';   # Inherit legacy format()

method stringify ($data) {
    use My::Own::Dumper;
    return My::Own::Dumper->new->dump($data);
}

When the Data::Show module is loaded with the single argument 'base':

use Data::Show  'base';

...it causes the current class to inherit the root plugin base class, Data::Show::Plugin.

Alternatively, when Data::Show is loaded with a named base argument pair:

use Data::Show  base => 'Data::Show::Plugin::Whatever';

...it causes the current class to inherit the specified base class (loading or autogenerating that base class, if necessary).

Modifying existing plugins

The object-oriented nature of the plugin mechanism also makes it easy to modify the dumping or formatting behaviour of an existing plugin.

For example, if you wanted to change the default behaviour of the builtin plugin for Data::Printer, so that it no longer shows tainting or colours, and so that it indents by eight columns instead of four, then you could create a derived plugin class and override its stringify() method:

class Data::Show::Plugin::Data::Printer::Custom;

# Inherit from the existing standard plugin...
use Data::Show base => 'Data::Show::Plugin::Data::Printer';

# Change the stringification behaviour...
method stringify ($data) {
    use Data::Printer;
    return np($data, show_tainted=>0, colored=>0, indent=>8, ) . "\n";
}

# and thereafter...

use Data::Show  with => 'Data::Printer::Custom';

Fallbacks

In addition to allowing the user to explicitly specify a fallback option , the module maintains an internal hierarchy of dumpers it can fall back on if the requested dumper (or the default dumper) is not able to be loaded:

                        Data::Dmp   Legacy
                         \______  ______/
                                \/
      Data::Dumper::Color   Data::Pretty   Data::Dump::Compact
       \________________________  __________________________/
                                \/
    Data::Dumper::Concise   Data::Dump   YAML   YAML::PP   YAML::Tiny::Color
     \______________  ______________/     \____________  _________________/
                    \/                                 \/
Data::Printer  Data::Dumper  Data::Dumper::Table  YAML::Tiny  Data::TreeDumper
 \____________________________________  ____________________________________/
                                      \/
                                  Dumpvalue

The idea is that when a specific dumper module is requested (or defaulted to) but cannot be loaded, the module will follow the arrows downwards through the preceding diagram, trying each alternative dumper module on that path through the tree.

So, for example, if the user requests Data::Dmp as their dumper, but it is not available, then the module will try Data::Pretty, then Data::Dump, then Data::Dumper, then Dumpvalue, accepting the first fallback it can load. Note that both Data::Dumper and Dumpvalue are core modules, so they should always be available in any standard Perl installation.

DIAGNOSTICS

Unknown named arguments: <ARGNAMES>

You loaded the module and passed a named argument with a name other than as, to, with, fallback, warnings, termwidth, grid, style, showstyle, datastyle, codestyle, filestyle, linestyle, or gridstyle.

Did you misspell one of those?

No value specified for named argument <ARGNAME>

You loaded the module and passed a named option ('with', 'to', 'warnings', etc.) but you didn't provide a value for that name. For example:

use Data::Show 'warnings';

If you really intended to specify that named argument with an undefined value, specify the undef explicitly:

use Data::Show 'warnings' => undef;

Although, because passing undef actually leaves the warnings on, in this particular example the user probably meant:

use Data::Show 'warnings' => 'off';
Unknown configuration options: <CONFIGNAMES>

You specified a configuration option in a .datashow file with a name other than: as, to, with, fallback, warnings, termwidth, grid, style, showstyle, datastyle, codestyle, filestyle, linestyle, or gridstyle.

Did you misspell one of those?

Can't specify 'base' as a configuration option in <CONFIGFILE>

It doesn't make sense to specify 'base' in your .datashow configuration file. A 'base' specification causes the current class to inherit a plugin class. But there's no current class in a configuration file, so specifying a 'base' value is pointless there (and probably indicate a misunderstanding of the 'base' option).

Just remove the configuration option from your .datashow file.

If 'base' is specified, it must be the only argument

The 'base' named argument causes the current class to inherit a specified plugin class. It does not export or configure show(), so any other arguments are pointless (and probably indicate a misunderstanding of the 'base' option).

Remove any other named arguments from the use Data::Show call.

Could not open named 'to' argument for output

You specified a filename as an alternative output target, via a named 'to' argument, but the specified file could not be opened for output. For example:

use Data::Show to => "";

Check whether the filename is legal on your filesystem, and also whether the target directory, and any existing version of the file, are both writeable.

Named 'to' argument is not a writeable target

You specified a filehandle as an alternative output target, but the filehandle was not writeable.

Check whether the filehandle you passed is actually open, and then whether it is open for output.

<PLUGIN> requires <MODULE>, which could not be loaded

You requested a built-in plugin, but that plugin requires a module that could not be loaded.

Either install the required support module, or load Data::Show with:

use Data::Show warnings => 'off';

...to silence this warning and quietly use a fallback module instead.

Could not load <PLUGIN>

You requested a non-built-in plugin, but that plugin could not be loaded.

Check that the name of the requested plugin is correctly spelled, and that the plugin is actually installed somewhere in the current @INC path.

If you can't install the module, you can silence this warning and default to a fallback dumper with:

use Data::Show warnings => 'off';
Requested plugin class does not provide the following essential methods

You specified a non-builtin plugin, which was found and loaded, but which did not provide both of the two required methods for dumping information: stringify() and format().

See "Plugins" for an explanation of why these two methods are required, and how they work.

To ignore this warning and proceed to a fallback dumper module instead:

use Data::Show warnings => 'off';
Used <FALLBACK> in place of <PLUGIN>

You requested a plugin that could not be loaded, so the best available fallback was used instead.

You would have also received one or more of the three preceding diagnostics. Consult their entries for suggestions on silencing this warning.

Call to show() may not be not transparent

The call to show() has been inserted into a scalar context, but was passed two or more arguments to dump. This can change the behaviour of the surrounding code. For example, consider the following statements:

my @list = (
    abs  $x,
    exp  $y,
    sqrt $z,
);

sub foo ($angle) {
    return cos $angle,
           sin $angle;
}

If we add interstitial show() calls, as follows:

my @list = (
    abs  show $x,
    exp  show $y,
    sqrt show $z,
);

sub foo ($angle) {
    return cos show $angle,
           sin show $angle;
}

...then the addition of the show() calls actually changes the final contents of @list, and also changes the return value of foo() in scalar contexts.

This issue (and warning) never occurs in list or void contexts, and can generally be avoided in scalar contexts, by explicitly parenthesizing each call to show(), as follows:

my @list = (
    abs  show($x),
    exp  show($y),
    sqrt show($z),
);

sub foo ($angle) {
    return cos show($angle),
           sin show($angle);
}

Note that this approach also ensures that the various intermediate calls to show() occur in a more predictable sequence.

<MODULE> cannot show a <TYPE> reference

The stringification module used by your selected plugin was unable to stringify the particular data passed to show().

This may be due to a bug or limitation in the stringification module itself, or it may be because the target output format does not support rendering certain Perl datatypes. For example, YAML::Tiny deliberately supports only a subset of the full YAML output format and cannot represent references to scalars or qr regexes. So Data::Show::Plugin::YAML::Tiny cannot stringify those two data types.

To be shown the particular data, choose another Data::Show plugin instead. For example, try Data::Show::Plugin::YAML instead of Data::Show::Plugin::YAML::Tiny.

Internal error: <DESCRIPTION>

Congratulations! You found a bug in this module. Please consider reporting it to the maintainer, who will be extremely grateful to you.

CONFIGURATION AND ENVIRONMENT

You can change the default values for the 'with', 'to', 'warnings', and all other options to a use Data::Show; by specifying either a local or a global configuration file.

If a use Data::Show call does not specify an explicit 'with' or 'to', the module looks first for a .datashow file in the current directory, and then for a .datashow file in the home directory.

The contents of each of these configuration files must be a series of key:value pairs (in the typical INI format). The keys can be any valid named argument that can be passed to a use Data::Show import, except 'base'. As in many other INI config files, you can use = instead of : if you prefer, and any line that starts with a # is ignored as a comment.

So, for example, you could change the global default plugin (for example, from Data::Pretty to Data::Printer), and change the default output destination (from STDERR to the file datashow.log in the current directory), and change the default styling of output (to something slightly more subtle because you have an ANSI-256 colour terminal), by creating a ~/.datashow file containing the following lines:

# Change default dumper...
with: Data::Printer

# Change default output target...
to: ./datashow.log

# Change the styling...
showstyle: bold italic ansi75
codestyle:      italic ansi246
filestyle: bold italic ansi27
linestyle: bold italic ansi27
gridstyle:             ansi27
datastyle: bold        white

See the file sample.datashow in the module's distribution for a full example of a potential .datashow configuration file, in which all the configuration values happen to be the default values for those options (i.e. installing sample.datashow as your .datashow should have no effect on the module, if you're loading it without named arguments).

DEPENDENCIES

This module only works under Perl 5.10 and later.

The module requires the PPR module.

It will also require any non-core module that is itself required by a plugin you select.

However, the requested non-core module is not actually required; if it cannot be loaded, the plugin request will be ignored and a fallback will be used instead.

INCOMPATIBILITIES

None reported.

BUGS AND LIMITATIONS

The module uses a complex PPR-based regex to parse out the call context from the source. Hence it is subject to the usual limitations of this approach (namely, that it may very occasionally get the argument list wrong).

Also, because the module uses the PPR module, it will not work under Perl v5.20 (due to bugs in the regex engine under that version of Perl).

No other bugs have been reported.

Please report any bugs or feature requests to bug-data-show@rt.cpan.org, or through the web interface at http://rt.cpan.org.

AUTHOR

Damian Conway <DCONWAY@CPAN.org>

LICENCE AND COPYRIGHT

Copyright (c) 2010-2024, Damian Conway <DCONWAY@CPAN.org>. All rights reserved.

This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See perlartistic.

DISCLAIMER OF WARRANTY

BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENCE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.