Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to handle errors gracefully instead of aborting #23

Open
1 of 3 tasks
bertfrees opened this issue Mar 25, 2021 · 2 comments
Open
1 of 3 tasks

Option to handle errors gracefully instead of aborting #23

bertfrees opened this issue Mar 25, 2021 · 2 comments
Assignees

Comments

@bertfrees
Copy link
Contributor

bertfrees commented Mar 25, 2021

It is a wish of some users to be able to get an output from a (valid) OBFL document regardless of whether there were issues during the conversion. If possible, a valid PEF should be returned, even if it's not the "correct" result, and another return value should indicate whether the PEF is "correct" or not.

It's important to make a distinction between unexpected errors (due to bugs in Dotify), validation errors and other errors. The new option would only have an effect on the last category.

Examples:

  • Not enough space in left or right page margin to render content
  • Not enough space in header or footer to render content
  • Not enough space to render a table with a lot of columns

(A lot more examples can be thought of. We should probably go through the whole code and categorize all the exceptions that are thrown.)

Some errors will be harder to handle gracefully than other. We don't need to handle them all but we should do a best effort.

@bertfrees
Copy link
Contributor Author

We agreed that it is a good thing in general to try to do a best effort when something can not be rendered according to the OBFL contract, but also provide the option to not deviate from the contract (abort if needed).

However how to best handle it is to be decided case by case.

  • In some cases there might be a reasonable fallback that could be always be applied, without the need for a setting. We might have to clarify the new behavior in the OBFL spec.
  • In some cases it could make sense to give the use control through a new OBFL feature, like an attribute to enable or disable a fallback.
  • In some cases it could be more appropriate to have a Dotify setting.
  • Sometimes it might make sense to have a combination.

@kalaspuffar kalaspuffar transferred this issue from mtmse/dotify.formatter.impl Aug 20, 2021
@bertfrees
Copy link
Contributor Author

Note that there is already a allowsTextOverflowTrimming option in FormatterConfiguration which could be reused.

bertfrees added a commit to bertfrees/dotify.library that referenced this issue Jan 11, 2022
…argin

(to render a marker-indicator) when the "allowsTextOverflowTrimming"
option is set. Instead show a warning.

This addresses Github issue
mtmse#23 about "handling
errors gracefully instead of aborting".
bertfrees added a commit to bertfrees/dotify.library that referenced this issue Feb 14, 2022
…argin

(to render a marker-indicator) when the "allowsTextOverflowTrimming"
option is set. Instead show a warning.

This addresses Github issue
mtmse#23 about "handling
errors gracefully instead of aborting".
kalaspuffar pushed a commit that referenced this issue Feb 14, 2022
…argin (#35)

(to render a marker-indicator) when the "allowsTextOverflowTrimming"
option is set. Instead show a warning.

This addresses Github issue
#23 about "handling
errors gracefully instead of aborting".
bertfrees added a commit to bertfrees/dotify.library that referenced this issue May 31, 2022
kalaspuffar pushed a commit that referenced this issue Jun 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants