# How ca I determine if file.openWithDefaultApplication() succeeds

An app written mainly for windows users.

I have a a bunch of files that I allow users to choose from and then I have middle tier code to shoot the stream at the AIR application, which nicely writes it to disk. I then use

file.openWithDefaultApplication()

to try to open the file, and it works swimmingly for most file types, not not everyone will have an association for every file type stored on the server. I need to know when this eventuality occurs, so I can do something different.

The docs say;

Error — (Mac OS and Linux) No application was found that can open the file. (On Windows, attempting to open a file that has no associated application fails silently, without an exception.)

So how can I tell whether a file will open or has opened?

have you tried to listen for IOError ?

eg.

IOError — The file does not exist or no application is registered to open the file.

If that does not work then you can use NativeProcess
so you can test from the command-line if a particular extension is associated to an application

ASSOC

ex:

C:\> ASSOC .doc
.doc=Word.Document.8

C:\> ASSOC .pdf


FTYPE

C:\> FTYPE Word.Document.8
Word.Document.8="C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE" /n "%1" /o "%u"


START

ex:

C:\> START "" "C:\\path\to\file.ext"

1 Like

Actually I tried everything I could think of. Here is one iteration. It always executed with no exceptions.

		private function reportCompletionHandler(localFile:File):void
{
CursorManager.removeBusyCursor();
var strFilePath:String = localFile.nativePath;
var file:File = File.applicationDirectory.resolvePath(strFilePath);
trace("Trying file.openWithDefaultApplication()");
try
{
file.openWithDefaultApplication()
}
catch (err:Object)
{
trace("file.openWithDefaultApplication() Error = " + err);
}
}
private function DefAppErrorHandler(event:Event):void
{
trace("DefAppErrorHandler=" + event.toString();
}

you can catch different type of errors

try
{
file.openWithDefaultApplication()
}
catch( e:Error )
{
// deal with Error
}
catch( e:IOError )
{
// deal with IOError
}
catch( e:ReferenceError )
{
// deal with ReferenceError
}


eg. here you want to see if you got an IOError
if that does not show then you will have to use NativeProcess to deal directly with the command-line

I may be wrong on this but since IOError and ReferenceError are both inheriting from Error would the first catch not always be the one which is entered and never one of the latter?

1 Like

it doesn’t work exactly like that

the ActionScript 3.0 Developer’s Guide has a great chapter on Handling errors

all your errors should inherit from Error, and yeah if you want to catch a custom error first, you should have it first in the order of catch calls

Each catch statement identifies a specific type of exception that it handles. The catch statement can specify only error classes that are subclasses of the Error class. Each catch statement is checked in order. Only the first catch statement that matches the type of error thrown runs. In other words, if you first check the higher-level Error class and then a subclass of the Error class, only the higher-level Error class matches.

so yeah in what I showed above you should catch Error last
but still multiple catch with multiple of errors is a pretty great feature

I mainly mentioned that because I saw in @aceinc answer
file.addEventListener(IOErrorEvent.IO_ERROR ...
and catch (err:Object)

it’s not badly wrong, but not exactly the same thing as doing a
catch( e:IOError )

IOErrorEvent is asynchronous will only be dispatched as an event
IOError is synchronous will only be thrown in a try...catch

even if you can throw any type of object, eg. throw new String("yep that works")
you don’t really want to catch anything using catch( e:Object ) or catch( e:* )
because indeed you can use multiple catch

errors (and events too) are the kind of “little” things where dev should try to follow best practices,
I’m probably too much into it because of Redtamarin where I’m forced to really go deep in all those mechanisms, but yeah it matters quite a lot, well … let’s stop here before I write pages about it

1 Like