caught File.open() exception and print error

[doge1024]

No description provided.

[dblock]

What are you seeing now that you wanted to catch this error? What was the old behavior vs. new behavior?

I am not saying we don't want this, but there are things I dislike:

• There can be a lot of other errors and handling them all over the place is an anti-pattern.
• You are trapping all errors, it should be more specific possibly.
• If we want to handle specific file errors we could put them into https://github.com/dblock/fui/pull/40/files#diff-29fc09890b6cfd5b35fc2f78977fcdbf92808a02ca4ca02938cd7f4f33793664R30.
• I dislike an exit in the middle of the code that aborts things, if you want to display a better error you can catch a specific one, log a better error, then re-raise.

[dangerpr-bot]

	2 Warnings
⚠️	[DEPRECATION] check is deprecated. Please use check! instead.
⚠️	Unless you're refactoring existing code or improving documentation, please update CHANGELOG.md.

Here's an example of a CHANGELOG.md entry:

* [#40](https://github.com/dblock/fui/pull/40): Caught file.open() exception and print error - [@doge1024](https://github.com/doge1024).

Generated by 🚫 Danger

[dblock]

What the contributor did: Wrapped process_code and process_xml in begin/rescue to catch any exception when reading/processing a file, print an error message, and call exit -1.

The motivation: Almost certainly the same invalid byte sequence in UTF-8 error from issue #37 — the contributor hit it and wanted to at least print a useful message instead of a raw
backtrace.

Do we want this? No, and we already did it better:

1. Root cause fixed — PR Fix ArgumentError: invalid byte sequence in UTF-8 for non-UTF-8 files #47 already solves the underlying problem by reading files as binary and transcoding to UTF-8. The error simply no longer occurs.
2. The implementation has real problems (which dblock called out):
   - Catches all exceptions (rescue => e) — way too broad
   - process_xml has a bug: uses bare rescue (no => e) but then tries to print #{e} — would raise a NameError instead of helping
   - exit -1 deep inside a library method is an anti-pattern; libraries should raise, not exit
   - Silently exits on any file error — no retries, no skip-and-continue

Verdict: Close it — the underlying issue is resolved properly by #47, and this approach was the wrong fix even as a stopgap.