Re: Serious bug in MatchQ causes crashes and incorrect results
- To: mathgroup at smc.vnet.net
- Subject: [mg28285] Re: Serious bug in MatchQ causes crashes and incorrect results
- From: Jeff DuMonthier <jjdmon at erols.com>
- Date: Sat, 7 Apr 2001 03:44:43 -0400 (EDT)
- References: <9aem2g$nc6@smc.vnet.net> <X4cz6.18682$uR4.183244@ralph.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
In article <X4cz6.18682$uR4.183244 at ralph.vnet.net>, Jens-Peer Kuska
<kuska at informatik.uni-leipzig.de> wrote:
> Hi,
>
> you call Abort[] and you are wondering *why* the system crash.
> Whow ... I have a similar problem on my PC, every time I press
> the key with the "Reset" label to terminate a program the
> computer reboots and all my data are lost.
>
> Abort[] kill your full computation in a very hard way, you should
> use something like Break[] or Return[] to hinder the Kernel
> to continue its computation. In harder cases you may try a
> Catch[]/Throw[] pair. But never, *never*, NEVER, N_E_V_E_R
> use Abort[]
>
The reason I use 'Abort[]' is to stop the Kernal from generating
hundreds of useless error messages after I know something has failed.
I have used it quite a bit on both the Mac and under Solaris with no
problems. I sometimes do use 'Throw[]'.
> Since Abort[] is so brutal it is very likely that a wonderfull
> stable system like MacOS crashes ...
>
As I said, it has worked fine for me before. The code worked before I
added calls to 'MatchQ[]' and it works again if I remove them. The
crash actually occurs with well conditioned arguments where 'Abort[]'
does not get called.
> BTW: I expect that the whole function is nonsense because FileNames[]
> *can* only return a list of strings or an empty list, both should match
> {_String...}. So it is useless to test it. And it always better and more
> clear to have a rules
>
> getFile[file_]:=
> getFile[file_,{}]:=
> getFile[file_,dirs:{_String..}]:=
>
> Regards
> Jens
>
The file names are generally being entered manually, not returned by
'FileNames[]' so they do need to be checked. The approach of checking
argument patterns and aborting if they don't match came out of
difficulty in defining both complex patterns and default values for the
arguments. I still don't understand the syntax for some of the
suggested solutions. If I could define complex patterns with default
arguments could I then define a version of the function to match all
invalid argument patterns such as:
getFile[___]:= CompoundExpression[Message[]; Throw[]/Abort[] ]; ?
-Jeff DuMonthier