Error Handling

[johnt53984649]

I'm writing an HTML panel for Photoshop for personal use, and when a button is clicked, the following function in a .jsx file is called, and then EvalScript updates a text field with the path of the current open document.

function getcurrentfilepath()
{
  return app.activeDocument.path.fsName;
}

But I run into problems whenever the button is clicked and there is no document open, or the document that is open hasn't been saved yet.  So in these instances, the text "EvalScript error." ends up in my text box.  See the image below:

I would like to be able to control what text is returned whenever the error occurs.  So that means that I need to add code into my .jsx file so account for situations in which the app.activeDocument.path.fsName property is not valid.  So essentially, I need to do error handling.  But I'm not sure how to check if that property is valid.  So how can I change my function to return a different string whenever the app.activeDocument.path.fsName is not valid?

[Kukurykus · Accepted solution]

$.level = 0; try{activeDocument.path} catch(err) {err.description}

[johnt53984649]

Thanks, I didn't realize that trying to get a property like that could throw errors.  I also didn't realize it worked basically the same way it does in C++.

[Loic.Aigon]

rather than try/catch, just check at app.documents.length property. If 0 then no documents are actually open.

And as for the path, new documents lack (unless I am wrong) a proper extension in their name. So this control should work too:

/\.[a-z]{2,4}$/.test( app.activeDocument.name ) //true > saved so path should be available; false > not saved yet

[Kukurykus]

I wanted to suggest it but it's risky. What if somone create new document with for example name like: "new.document.one"? Your code will say that document is saved while it's not. Btw I use that you proposed in some of my scritps. But they are for only personal usage, and there is no way dot could occur in file name more than once, as I care of it was like it. But generally it's not good way for checking is opened documentd un(saved) in case of custom users.

[Loic.Aigon]

I admit there is a possible flaw. One may think of specifying extensions in the regular expression but sill it wouldn't prevent someone to type in my.pseudo.psd where psd would be part of the name and not the extension by itself.

[xbytor2]

>>Thanks, I didn't realize that trying to get a property like that could throw errors.

This happens in more than a few places in PSJS. Since they are not documented, you stumble across them, add the try/catch, and move on. Some less than ideal decisions were made during the original design of the PSJS API.