https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24574 --- Comment #16 from David Cook <dcook@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.