Re: Avoid assertion error for statement probe

[Mark Wielaard <mjw@redhat.com>]

On Mon, 2009-08-10 at 17:25 +0800, Wenji Huang wrote:
> Frank Ch. Eigler wrote:
> [...]
> >> $ stap -e 'probe process("./stap").statement("foo@main.cxx:*") {}'
> >> semantic error: no matched function 'foo' in main.cxx
> >> semantic error: no probes found
> > 
> > Not a bad idea, but perhaps we don't need that particular "no matched
> > function" message that covers just this case, considering that the "no
> > probes found" message can/should be paired with the probe point.

I always found the extra "no probes found" exception error message
confusing. Clearly stap did find a probe, that is why is was giving an
error about it in the first place. Adding "no probes found" after that
is IMHO confusing. It should only say that if there were no other
errors. The following makes it that way:

commit 8c938ec723aad41c6cafcdef24679d40f310396c
Author: Mark Wielaard <mjw@redhat.com>
Date:   Mon Aug 10 17:44:31 2009 +0200

    Only add extra error on no probes found if no previous errors already shown.
    
    * elaborate.cxx (semantic_pass): Don't add "no probes found" if session
      already had other errors.

diff --git a/elaborate.cxx b/elaborate.cxx
index 9350023..1d7f793 100644
--- a/elaborate.cxx
+++ b/elaborate.cxx
@@ -1455,7 +1455,7 @@ semantic_pass (systemtap_session& s)
       if (rc == 0) rc = semantic_pass_vars (s);
       if (rc == 0) rc = semantic_pass_stats (s);
 
-      if (s.probes.size() == 0 && !s.listing_mode)
+      if (s.num_errors() == 0 && s.probes.size() == 0 && !s.listing_mode)
         throw semantic_error ("no probes found");
     }
   catch (const semantic_error& e)

> How about to defer the error to the outer calling ?
> 
> $ stap -e 'probe process("./stap").statement("foo@main.cxx:1025-1026") {}'
> semantic error: no match while resolving probe point 
> process("./stap").statement("foo@main.cxx:1025-1026")
> semantic error: no probes found
> Pass 2: analysis failed.  Try again with another '--vp 01' option.

Yes, I think this is a more informative error than your first version.

Cheers,

Mark