Exceptions in Document.Import (with parameter ImageImportOptions)

[armins32]

Hello,

we use many calls to Document.Import to display image tiles placed in the manner of a grid in a floor view.

This is the API Method we use:

C#

public bool Import(
	string file,
	ImageImportOptions options,
	View view,
	out Element element
)

Most of the time it works very well.

However, recently we received a customer report about this method raising an exception.
Even worse, the exception message does not help to understand the cause of the problem:

Error message
 Un composant externe a levé une exception.

Stack trace
 à FileImportExport.importImage(ADocument* , ImageImportOptions* , ElementId* )
 à Autodesk.Revit.DB.Document.Import(String file, ImageImportOptions options, View view, Element& element)

Sorry about the french message, I believe in english the exception message would read like "an external component has raised an exception".

Did anyone experience similar problems? Are there any ideas about the cause or why the exception message is so vaguely phrased? Are there any ideas for a workaround or how we could avoid this?

Thanks,

Armin

[eason.kangEDLV4]

Hi Armin,

Apologizing for the late, we have a backlog in the queue.

Did you know the Revit version and specific image information that your customer wants to import? For example, image type, image resolution, and file size?

In the same time, I didn't see this error on my side, so could you consider providing a none-confidential reproducible test case demonstrating this issue to me? I'm glad to help you figure out what happened, and pass it to our engineering team if needed.

Here is the reproducible test case definition form my colleague Jeremy's blog [link]:

The best and clearest way to describe an API problem is normally by providing a non-confidential reproducible test case including a minimal sample macro embedded in a minimal project file to run it in and detailed step-by-step instructions specifying exactly what you are trying to achieve, the behaviour you observe, the difference between the two and how to reproduce the issue to analyse it in the debugger:

• A short exact description of what you are trying to achieve.
• The behavior you observe versus what you expect, and why this is a problem.
• A complete yet minimal Revit sample model to run a test in.
• A complete yet minimal macro embedded in the sample model or Visual Studio solution with add-in manifest that can be compiled, loaded, run and debugged with a single click to analyze its behavior live in the sample model.
• Detailed step-by-step instructions for reproducing the issue, e.g. which element to pick, what command to launch etc.

The purpose of this is both to enable us to reproduce and analyze the problem and to verify that it really has been resolved. Another even more beneficial aspect for all involved is that creating a minimal reproducible case like this can help you discover for yourself what you were doing wrong, and the issue becomes moot.

Cheers,

[armins32]

Hi Eason,

---

@eason.kangEDLV4 wrote:

Did you know the Revit version and specific image information that your customer wants to import? For

example, image type, image resolution, and file size?

---

Our customer uses Revit 2017.

The image import happens during one of our command implementations.
During the command, many png images of size 1024x1024 are created in a sequential manner.
Each of them is created in a temp directory, only for the purpose to call "Import" and being able to pass the file path of the image file.
Afterwards the 1024x1024 png image is deleted immediately.

---

In the same time, I didn't see this error on my side, so could you consider providing a none-confidential reproducible test case demonstrating this issue to me? I'm glad to help you figure out what happened, and pass it to our engineering team if needed.

---

I know that it would be a big help, if a reproducible test could be provided.

Unfortunately, we could not reproduce it. We even had the customer upload the Revit project and the point cloud, but even with their data, we were not able to reproduce it on our side.

Our hope was more like your engineering team would look into the spot where that exception could be thrown and try to give at least some more information about it - even if only rough information could be provided.

Of course we understand, that exceptions can occur at any time if something has gone badly wrong. On the other hand, the exception concept should also serve the purpose to give an idea what has gone wrong.

But if we look at the exception as it is, there is almost no hint at all. "An external component has thrown an exception".

1. "An external component" has raised the exception. Ok. But which one, can you name it?
2. "...has thrown an exception" that's for sure, we can see that. But what is the reason that the exception has been raised? Usually an exception message should be more specific about the cause of the problem.

I think in that regard, there would be room for improvement in that API function (and probably in others, too).

It's only an idea, if any additional information could be provided to help us to get an idea about possible causes.

If so, it would be nice to let us know.

Thanks so far and best Regards,

Armin

[eason.kangEDLV4]

Hi Armin,

Thank you for your feedback~

Well ... I agree that some error messages are ambiguous. Apologizing for any inconvenience had caused to you. I can help to log a request acquiring error message improvement of the Revit API.

But where did you see this error message "An external component...has thrown an exception"?  From Revit UI without attaching debugger of the  Visual Studio? If this error shows up from your customer side, may I ask you a favor to add a try-catch block like the below for example and make a debug version of your add-in for your customers to identify which exception Revit did throw exactly?

try {

    // Your import code here

} catch(Exception ex) {
    var message = ex.InnerException == null 
                     ? ex.Message 
                     : ex.Message + " --> " + ex.InnerException.GetFullMessage();

    TaskDialog.Show( "Revit API Error", message );
}

According to the documentation here (http://www.revitapidocs.com/2017.1/493d203e-ef4c-b447-f979-52b22725b2ad.htm), there is only one exception will be thrown, Autodesk.Revit.Exceptions ArgumentNullException, if there is an invalid function input. I'm just wondering if there is another error occurred while calling image import API, that will be a great help to me to communicate with our Revit team. 

BTW, there are many properties might help you to check the error details, please see this page: http://www.revitapidocs.com/2017.1/d12dbacb-0a56-e0c3-cddf-b3236ff89a51.htm

Cheers,

[armins32]

Hi and sorry, I lost track of this issue for some time.

Thanks for the suggestion regarding try-catch statement, but actually that's what we always do in the outmost context of our code implementation of toolbar commands. Whenever an exception is caught in that outmost context (and if it wasn't handled in the inner implementation), we show a dialog to the customer, showing the exception content with a "Copy to clipboard"-button and guiding them to send us a mail with the content.
That's how we received the exception text in the first place:

Error message
 Un composant externe a levé une exception.

Stack trace
 à FileImportExport.importImage(ADocument* , ImageImportOptions* , ElementId* )
 à Autodesk.Revit.DB.Document.Import(String file, ImageImportOptions options, View view, Element& element)

So, as far as I'm concerned, it is proven that the importImage method can throw (at least one) more exception(s) than only ArgumentNullException.

The suggestion to make a "debug plugin" for our customer is not an easy task at all, because our plugin is more like a big application consisting of different components/dll's. It would take a lot of work to deliver a debug variant. It's unlikely our management agrees to choose this way just to find more information about the type of the exception. It's a good idea, but also a question of cost and benefit.

Best Regards,

Armin