NFD » ndn-cxx

I haven't yet seen the diagnostic message output and don't remember how it looked like. But I think it would be rather verbose and not entirely user friendly. Should we enable it only in certain circumstance (like when compiled in debug mode)?

Crashing is never user friendly anyway. But if it's a real bug and the user opens a ticket with the extended error message, it'll be easier for us, and better than asking to (re)build in debug mode and try to reproduce the crash. So I think we should always print the extended info.

There is a dispute on whether to print diagnostic information in ndnsec top-level catch.

ndnsec top-level catch is serving dual purposes:

• Catch and print a legitimate error, such as "Key not found". In this case, it's better to print the error message e.what() only without diagnostics.
• Catch unexpected error, such as TLV decoding errors. In this case, diagnostics are useful.

We should distinguish between these two purposes (using two or more separate catch branches with different types), and skip diagnostics for all legitimate errors.

Junxiao Shi wrote:

ndnsec top-level catch is serving dual purposes:

• Catch and print a legitimate error, such as "Key not found". In this case, it's better to print the error message e.what() only without diagnostics.

This is abusing exceptions. "key not found" is not an exceptional case. In such case the program knows exactly what's wrong and how to solve it (exit with a clear error for the user). So you simply shouldn't use exceptions for this case.

• Catch unexpected error, such as TLV decoding errors. In this case, diagnostics are useful.

We should distinguish between these two purposes (using two or more separate catch branches with different types), and skip diagnostics for all legitimate errors.

Don't use exceptions for non-exceptional cases.

I agree with note-7.

I recommend this to proceed as follows:

• Don't add diagnostics in ndnsec.
• Create a separate issue to avoid exceptions in non-exceptional cases; ndnsec top-level catch should add diagnostics in that issue.

Is there a consensus on how we should proceed with this issue?

I agree with note 8 only partially. I would revert changes in ndnsec tools, but I don't agree with other changes. Exception that are throws from security classes are exceptional cases and need to be reported to users. ndnsec tools are user facing tools and users just need a high-level error (we may need to update error messages to make errors more user friendly in some cases).

We can also revert any changes in other tools, as they will be removed from the library anyways.

For NFD (I think it should be just nfd, not other tools), we need to agree on a reasonable format of the error message. I would like to see just content of what(), file name and line number of the place the error was thrown (if available).