There are several sub-issues here:

     a) Can the implementation call the error handler even if all
        API calls are done with a non-NULL SceMiEC pointer?

     b) Is it OK to mix the error handling styles (NULL and non-NULL
        SceMiEC) on different calls?

     c) The recoverable error thread which split into three threads:

          http://www.eda.org/itc/hm/0272.html
          http://www.eda.org/itc/hm/0285.html
          http://www.eda.org/itc/hm/0288.html

        John started down the road to propose changes to the spec
        to introduce a recoverable error type, but then retracted
        his proposals because he felt that the spec already has
        everything it needs to support the handling of recoverable
        errors.  The only outstanding issue is how to report a
        failed lookup of an integer attribute (AttributeIntegerValue()).
        We cannot simply use a 0 return value to indicate the case
        where the attribute did not exist.

======================================================


in SCE-API, if the application always uses a non-NULL SceMiEC 
in any SCE-API it calls, does it then follow that the SCE-MI 
error handler will never be called? I mean, is the implementation 
required to ensure the error handler is never called in this 
case? The may sound like a trivial question, but consider that 
implementations may use callback functions such as signal handlers, 
interrupt routines, etc., that may run outside of any call-chain 
initiated by an SCE-API call. If those functions gets errors, 
there is no non-NULL SceMiEC pointer to use for error reporting 
and you are pretty much left with the error handler. But that 
may be surprising to the user who might reasonably expect that 
error handling is entirely in his hands in this case. 

Just to confirm, but I assume there is nothing wrong with mixing 
the two styles of error handling (NULL and non-NULL SceMiEC) in 
the same applications, right? 

In fact, using a non-NULL SceMiEC is useful when the application 
wants to probe the API. For example, it can be used to check 
if certain attributes exist in the parameter file or it can be 
used to attempt to bind to a port that may not always exist. 
This approach can be used to write more flexible application 
code that can work with several hardware configurations for 
example.