[ruby-core:36520] [Ruby 1.9 - Feature #4774] User Friendly Handling of "Encoding::ConverterNotFoundError"

Issue #4774 has been updated by Lazaridis Ilias.


=begin
Yui NARUSE wrote:

> > The basic action would be to extend the error message "Encoding::ConverterNotFoundError" like this:

> In current situation, users can do nothing, so such message is useless.

This is not exactly true.
 * I did something (filed issue #4738), and my problem was solved.
 * even if the user can do nothing: he should be informed

> Or such message is associated with the rdoc of the method which raises Encoding::ConverterNotFoundError.

A new user does not know about rdoc.

Possibly he could be pointed to an issue here.

> > A developer locates the relevant missing file, e.g.: "ibm737-tbl.rb", and place it into the sources for the next release. 

> We don't recommend such hack even if people may do it.

This is what the developer has done in my case: #4738


> > The existent installation of the user has still the problem - he has to wait for the next release.

> He should report it before 1.9.2 is released.

Nobody knows when a user hits on a "ConverterNotFoundError".

> Especially IBM737, it is unintended missing file and should be reported.

I've reported it already, and the file was added to the repo: #4738

But I invest some time, thus ruby becommes better.

A new ruby user should be informed about this problem.

Imagine this scenario:

* Someone downloads and installs ruby, python and perl on his windows laptop.
* he starts to look around a little, and installs some software for all the 3 systems
* the ruby installation hits on the "ConverterNotFoundError"

He continues with perl and python, and finally gets exited about python, or:

* He follows the link in the error messages, follows the instructions, the team reacts and adds the missing transcoder
* He gets exited about how well organized all this, and gets exited about ruby.

The ruby team cannot leave users alone with this. The current design has a weakness (none knows on which machine the error will happen). 

So, filing an issue (or pointing to a webpage) with information, and pointing to this from the error message, this is the very first step.

> > The final possible implementation (and possibly the most elegant one) would be, to have the preliminary encoding-translations within a gem.

> It is sometimes discussed, but not implemented yet.

> We consider it is possible but not easy.

You are language developers, so things can be difficult.

Am easy extension of the existent system could(!) be:

(I don't know the name, I call it "transcode-library" for now)

Status:

* The transcode-library has an include path, where it fetches the transcoder *.so's (e.g. enc/trans)

Changes:

* The transcode-library is modified, thus it can look for the *.so's in multiple paths/locations
* The transcoder gem would add itself to the include path when installed (and remove itself, when deinstalled)
  * e.g. whilst calling "transcoder.add_path"

(I can take the time to look deeper into this, if there's a possibility that it will be implemented) 

=end

----------------------------------------
Feature #4774: User Friendly Handling of "Encoding::ConverterNotFoundError"
http://redmine.ruby-lang.org/issues/4774

Author: Lazaridis Ilias
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Based on my own (user) experience with issue [#4738] (which was solved), I suggest the following enhancement.

=== 1st Step - Minimum ===

The basic action would be to extend the error message "Encoding::ConverterNotFoundError" like this:

"
Converter XXXX to XXXX not found. 
More information on: http://ruby-lang.org/encoding-converter.html
"

The document would explains why this error happened, and what the user can do now.

Example: 

  please run "ruby --encode-sanity" and send the output to ...
  Search in "http://redmine.ruby-lang.org" for "converter XXX to XXX"

(something like that, that give a process to follow)

A developer locates the relevant missing file, e.g.: "ibm737-tbl.rb", and place it into the sources for the next release. 

The existent installation of the user has still the problem - he has to wait for the next release.

=== 2nd Step - Preliminary Encoders ===

The user would have the possibility to drop-in a translation table file. The file "ibm737-tbl.rb" is published on the "encoding-converter" page, the user gets it and drops it into it's local installation, e.g.:

ruby192/lib/enc/trans/preliminary/

The exception (Encoding::ConverterNotFoundError) tries to resolve the missing translation table with a lookup to a preliminary/*.rb table (which has lower speed, but it works).

With the next release, the file would become redundant, because it was compiled in. A message could inform the user about it.

-

=== Alternative - By Compilation ===

If the compilation of the translation tables is unavoidable by design, then the site 

http://ruby-lang.org/encoding-converter.html

could point to the relevant compiled *.so files

In this case, the missing *.so file would be generated out of "ibm737-tbl.rb", and provided for download (for the major OS, Win, Mac etc.!)

The files could be "stolen" from actual automated builds (don't know if currently available for ruby).

=== gem based ===

The final possible implementation (and possibly the most elegant one) would be, to have the preliminary encoding-translations within a gem.

So, in this example, ibm737-tbl.rb would have been placed into the ruby sources, and the actual "trans" gem would have been updated and uploaded (with native versions for the major OS's).

The user would update his local installation by:

chcp 850 => change codepage to 850 or something else, thus gem works
gem install encoders => installs the encoding-translation which was just updated with ibm737-tbl.rb
chcp 737 => change back to original codepage

This way the user can continue with his install ruby immediately, and the sources are updated

-

(please note: I'm not familiar with the ruby sources. I've invested some hours to write this down, thus a core developer with the relevant domain knowledge can verify and possibly implement this.)




-- 
http://redmine.ruby-lang.org