[Koha-bugs] [Bug 24574] Broken MARC records cause "invalid data, cannot decode object" on ISBDdetail and MARCdetail pages.

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24574

--- Comment #16 from David Cook <dcook at prosentient.com.au> ---
(In reply to Rudolf Byker from comment #4)
> In CS, this is known simply as "Robustness". This is also why many
> programming languages have the pattern of "checked exceptions", which forces
> you to either handle an error/exception or re-throw it to be handled
> elsewhere. I'm not a Perl programmer, so I'm not sure what the Perl
> equivalent of that would be.
> 

If I understand correctly, "checked exceptions" refer to exceptions that are
caught during compile-time, but the error you're encountering is a run-time
error. (As far as I know, core Perl doesn't have "checked exceptions", but they
might be enabled by third-party modules. Koha is starting to use
Exception::Class more, and I think it might have some support for compile-time
checks. But really that's irrelevant here.)

In terms of the run-time, it seems that your Koha is being run by Apache
executing the Perl scripts as CGI scripts. (The alternative being Apache acting
as a reverse proxy for Perl app server Starman which loads the Perl code into
its persistently worker processes and executing them.)

The final line in those CGI scripts is to write HTTP headers and parse/output a
page based on a Template::Toolkit template. 

If there is a fatal exception which causes the Perl interpreter to die before
it reaches the line that produces the HTTP response, then Apache doesn't have a
HTTP response to send back to the browser, and it has to send back an error
document. I'd have to double-check, but if the CGI script returns a non-zero
exit code, I think Apache will always generate a response with a HTTP 500
status code (which makes sense).

Now I'm surprised that Apache is not sending back the custom response located
at /cgi-bin/koha/errors/500.pl, as it is configured to do that. Instead it's
using its generic response document, which is not user-friendly. I'm going to
explore that in a separate bug report.

In any case, in order to handle exceptions in the CGI code, we'd have to wrap
all the existing code in a try/catch block. While that's technically doable,
there are hundreds and hundreds of CGI scripts, so that would be a massive
task. 

Plus, then there is the question of what you do when you catch the exception at
that high of a level. I suppose you could send a 500 HTTP status and send a
user-friendly message back in a generic error template. 

Of course, there's no saying we'd have to do it for all CGI scripts all at
once. We could do it incrementally starting with the ISBDdetail.pl and
MARCdetail.pl scripts. 

> An alternative to error handling is to prevent the error from happening at
> all. Some text parsers allow you to replace incorrectly encoded characters
> by a predefined string, like "?", thereby silencing any encoding errors in
> the input. Whether this is acceptable, is a decision that depends on the use
> case.

Yeah, I don't think we handle encoding errors in MARC records very well. This
is a pet peeve of mine.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.