Smalltalk › Pharo › Pharo Smalltalk Developers

badDirectoryPath

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Sean P. DeNigris

badDirectoryPath

Administrator

lookupDirectory: fullPath filename: fileName
<primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'>
^ #badDirectoryPath

Why are we returning #badDirectoryPath instead of signaling an exception, maybe FileDoesNotExist?

Cheers,
Sean

EstebanLM

Re: badDirectoryPath

that was changed not much time ago, and... while I don't remember exactly while it was like that, I remember there was a good reason for that

On Jun 21, 2012, at 4:16 PM, Sean P. DeNigris wrote:

> lookupDirectory: fullPath filename: fileName
> <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'>
> ^ #badDirectoryPath
>
> Why are we returning #badDirectoryPath instead of signaling an exception,
> maybe FileDoesNotExist?
>
> --
> View this message in context: http://forum.world.st/badDirectoryPath-tp4635913.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Camillo Bruni-3

Re: badDirectoryPath

I would assume mostly due to performance....

this #badDirectoryPath happens quite often, hence it is much faster to do a
simple check

On 2012-06-21, at 16:32, Esteban Lorenzano wrote:

> that was changed not much time ago, and... while I don't remember exactly while it was like that, I remember there was a good reason for that
>
> On Jun 21, 2012, at 4:16 PM, Sean P. DeNigris wrote:
>
>> lookupDirectory: fullPath filename: fileName
>> <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'>
>> ^ #badDirectoryPath
>>
>> Why are we returning #badDirectoryPath instead of signaling an exception,
>> maybe FileDoesNotExist?
>>
>> --
>> View this message in context: http://forum.world.st/badDirectoryPath-tp4635913.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>
>

Sean P. DeNigris

Re: badDirectoryPath

Administrator

Camillo Bruni-3 wrote

I would assume mostly due to performance....

We should be clear on the reason and put a comment. This is an unusual (cough... c-like) pattern in Smalltalk.

Also, lookupDirectory:filename: returns #badDirectoryPath on primitive failure. Is that a good idea? It seems like it could lead to confusing errors ("what do you mean bad path?!?! I'm looking right at the @%#$ file!). Why not send primitiveFailed?

Cheers,
Sean

Camillo Bruni-3

Re: badDirectoryPath

On 2012-06-21, at 18:09, Sean P. DeNigris wrote:

> Camillo Bruni-3 wrote
>>
>> I would assume mostly due to performance....
>>
>
> We should be clear on the reason and put a comment. This is an unusual
> (cough... c-like) pattern in Smalltalk.
>
> Also, lookupDirectory:filename: returns #badDirectoryPath on primitive
> failure. Is that a good idea? It seems like it could lead to confusing
> errors ("what do you mean bad path?!?! I'm looking right at the @%#$ file!).
> Why not send primitiveFailed?

indeed!!

Igor Stasenko

Re: badDirectoryPath

is that primitive failed before?
from other side, answering #badPath.. is nicer than answering nil
(like opening a stream on non-existent file)
so, you can be sure that problem is not in something not properly initialized.

On 21 June 2012 18:18, Camillo Bruni <[hidden email]> wrote:

> On 2012-06-21, at 18:09, Sean P. DeNigris wrote:
>> Camillo Bruni-3 wrote
>>>
>>> I would assume mostly due to performance....
>>>
>>
>> We should be clear on the reason and put a comment. This is an unusual
>> (cough... c-like) pattern in Smalltalk.
>>
>> Also, lookupDirectory:filename: returns #badDirectoryPath on primitive
>> failure. Is that a good idea? It seems like it could lead to confusing
>> errors ("what do you mean bad path?!?! I'm looking right at the @%#$ file!).
>> Why not send primitiveFailed?
>
> indeed!!

--
Best regards,
Igor Stasenko.

Sean P. DeNigris

Re: badDirectoryPath

Administrator

Igor Stasenko wrote

is that primitive failed before?
from other side, answering #badPath.. is nicer than answering nil

I'm not sure I understand, but I'm not saying (necessarily) get rid of #badPath.., as there is apparently a good reason for it. I'm saying if the primitive fails - let's say the plugin is missing or whatever - we should distinguish that from #badPath..

Cheers,
Sean

Sean P. DeNigris

Re: badDirectoryPath

Administrator

It seems like the primitive is not returning enough context. badDirectoryPath is a catch-all for any error.

For example, if you send #entries to aFileReference on a directory where you don't have enough permissions, you get #badDirectoryPath. Besides being misleading - the path is not really "bad" - it's hard to deal with the error because it's so general. For example, DiskStore>>directoryAt:ifAbsent:nodesDo: has a bug (http://code.google.com/p/pharo/issues/detail?id=6122)...
...
entry := Primitives lookupEntryIn: encodedPathString index: index.
entry = #badDirectoryPath
ifTrue: [ ^ absentBlock value ].
...

So if the entry exists but the primitive fails (e.g. not enough permissions), the absentBlock is evaluated. It's easy enough to fix, but how would you signal a helpful error?

Cheers,
Sean

Cheers,
Sean

Igor Stasenko

Re: badDirectoryPath

i think, if you rename #ifAbsent: to #ifNotAvail:
then things can fit to their place :)

Not available = due to error/permissions/not exists ..
Absent = not exists/missing

On 22 June 2012 03:12, Sean P. DeNigris <[hidden email]> wrote:

> It seems like the primitive is not returning enough context. badDirectoryPath
> is a catch-all for any error.
>
> For example, if you send #entries to aFileReference on a directory where you
> don't have enough permissions, you get #badDirectoryPath. Besides being
> misleading - the path is not really "bad" - it's hard to deal with the error
> because it's so general. For example,
> DiskStore>>directoryAt:ifAbsent:nodesDo: has a bug
> (http://code.google.com/p/pharo/issues/detail?id=6122)...
> ...
> entry := Primitives lookupEntryIn: encodedPathString index: index.
> entry = #badDirectoryPath
> ifTrue: [ ^ absentBlock value ].
> ...
>
> So if the entry exists but the primitive fails (e.g. not enough
> permissions), the absentBlock is evaluated. It's easy enough to fix, but how
> would you signal a helpful error?
>
> Cheers,
> Sean
>
> --
> View this message in context: http://forum.world.st/badDirectoryPath-tp4635913p4636046.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

--
Best regards,
Igor Stasenko.