It blows my mind that the official document at MSDN doesn't say anything about what the underlying object type of the enumerable that returned by GetErrors of INotifyDataErrorInfo should be: http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifydataerrorinfo.geterrors(v=vs.95).aspx
Options are: System.String, System.Object, MyCustomObject, ISomeOtherShitThatDoesntHaveAnythingToDoWithValidationWhatsoever
Can anybody explain to me how an arbitrary enumerable of object can be OK for notifying about errors without making any assumptions about its structure?
The docs for INotifyDataErrorInfo give more information:
The validation errors returned by the GetErrors method can be of any type. However, if you implement a custom error type, be sure to override the ToString method to return an error message. Silverlight uses this string in its default error reporting.
Custom error objects are useful when you provide custom error reporting in the user interface. For example, you can create a template for the reporting ToolTip that binds to an ErrorLevel property in order to display warnings in yellow and critical errors in red.
There's a link in the Examples section of GetErrors back to that documentation:
For an example of an implementation of this method, see the INotifyDataErrorInfo class overview.
I agree it's less clear than it might be, but the documentation is there...
Related
I'm learning Rust and can't find a list of all error types. When a function is returning a Result, does the standard library have a group of predefined errors available for use?
I know custom error types can be made in Rust, is that the solution? Make all custom errors types?
It's not well defined what "an error type" would mean, so no, there is no global list of errors.
If you mean "is there a list of all the types that are used as Result::Err, the answer is still no. There are methods like slice::binary_search which return Result<usize, usize>. Is usize to be considered an error type? What if a Result::Err is constructed entirely inside of a function and never leaves it; is that type considered an error type? What about a generic type that contains a Result<i32, E>; should any concrete E be called an error type?
If you mean "is there a list of all the types that implement std::error::Error, then the answer is "kind of". See How can I get a list of structs that implement a particular trait in Rust? for details.
does the standard library have a group of predefined errors
Yes.
available for use
Sometimes. io::Error allows you to construct your own error value, but num::ParseIntError does not.
is that the solution? Make all custom errors types?
Generally, yes.
See also:
How do you define custom `Error` types in Rust?
Result types are often aliased in the standard library. If you see a function in the standard library documentation, you can click on Result, which should lead you to the aliased type (e.g. std::io::Result)
You can then see which kind of Error is used in the Result.
The documentation also has a list of all enums and structs in the standard library that implement the Error trait.
a list, although not complete, can be found at
https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/std/error/trait.Error.html
As you may know, it is pretty easy to have active code of a class containing syntax errors (someone activated the code ignoring syntax warnings or someone changed the signature of a method the class calls, for instance).
This means that also dynamic instantiation of such a class via
CREATE OBJECT my_object TYPE (class_name).
will fail with an apparently uncatchable SYNTAX_ERROR exception. The goal is to write code that does not terminate when this occurs.
Known solutions:
Wrap the CREATE OBJECT statement inside an RFC function module, call the module with destination NONE, then catch the (classic) exception SYSTEM_FAILURE from the RFC call. If the RFC succeeds, actually create the object (you can't pass the created object out of the RFC because RFC function modules can't pass references, and objects cannot be passed other than by reference as far as I know).
This solution is not only inelegant, but impacts performance rather harshly since an entirely new LUW is spawned by the RFC call. Additionally, you're not actually preventing the SYNTAX_ERROR dump, just letting it dump in a thread you don't care about. It will still, annoyingly, show up in ST22.
Before attempting to instantiate the class, call
cl_abap_typedescr=>describe_by_name( class_name )
and catch the class-based exception CX_SY_RTTI_SYNTAX_ERROR it throws when the code it attempts to describe has syntax errors.
This performs much better than the RFC variant, but still seems to add unnecessary overhead - usually, I don't want the type information that describe_by_name returns, I'm solely calling it to get a catchable exception, and when it succeeds, its result is thrown away.
Is there a way to prevent the SYNTAX_ERROR dump without adding such overhead?
Most efficient way we could come up with:
METHODS has_correct_syntax
IMPORTING
class_name TYPE seoclsname
RETURNING
VALUE(result) TYPE abap_bool.
METHOD has_correct_syntax.
DATA(include_name) = cl_oo_classname_service=>get_cs_name( class_name ).
READ REPORT include_name INTO DATA(source_code).
SYNTAX-CHECK FOR source_code MESSAGE DATA(message) LINE DATA(line) WORD DATA(word).
result = xsdbool( sy-subrc = 0 ).
ENDMETHOD.
Still a lot of overhead for loading the program and syntax-checking it. However, at least none additional for compiling descriptors you are not interested in.
We investigated when we produced a dependency manager that wires classes together upon startup and should exclude syntactically wrong candidates.
CS includes don't always exist, so get_cs_name might come back empty. Seems to depend on the NetWeaver version and the editor the developer used.
If you are certain that the syntax errors are caused by the classes’ own code, you might want to consider buffering the results of the syntax checks and only revalidate when the class changed after it was last checked. This does not work if you expect syntax errors to be caused by something outside those classes.
This is a follow-up question to Manual Conversion of 3rd Party Class With Morphia
I've an #Entity class which has a field of type javax.activation.MimeType. When I run my application I see a warning message in the output window, telling
WARNING: The multi-valued field
'javax.activation.MimeTypeParameterList.parameters' is a possible
heterogeneous collection. It cannot be verified. Please declare a
valid type to get rid of this warning. class java.lang.Object
I've already written and registered a type converter class for the type "MimeType", which effectively just ignores its 'parameters' field. But the warning keeps coming.I debugged it and saw that the warning was issued when datastore.ensureIndexes(); is called.
I tried writing a type converter for "MimeTypeParameterList" type but it didn't supress the warning. I can't just go and put a #Transient annotation over the field declaration because it's third party code (Java SE core!), not mine.
Is there an "elegant" way to eliminate this warning?
I just pushed a change to morphia's github repo that suppresses that logging for you. It'll be in 0.108 or you can build it locally if you want to try it out.
I'm writing a COM object that provides access to a service that must be explicitly connected before calls can succeed.
Is there a generic HRESULT code that describes that the callee object is in a state where it is unprepared to handle calls, ideally with the implication that this is the caller's fault?
Currently I'm using E_FAIL, which is too generic for my taste; OLE_E_BLANK might be an option, however this is not an OLE object and I'd rather not return a confusing error code.
I would suggest that E_NOT_VALID_STATE would be closest to what you want to convey.
But, as Hans says, implement IErrorInfo to give chapter and verse.
I'm trying to return a detailed error to VB6 using CComCoClass::Error, but it seems I can only return an error code /or/ a message - but not both.
return Error(_T("Not connected"), __uuidof(IMyInterface), HRESULT_FROM_WIN32(ERROR_CONNECTION_INVALID));
results in a generic "Method 'Request' of object 'IMyInterface' failed" error message in Err.Description on the VB6 side (but ERROR_CONNECTION_INVALID in Err.Number), while
return Error(_T("Not connected"));
results in the appropriate error message, but a generic error code in Err.Number. How can I get the best of both worlds?
You can't, this appears to be by design. Details further below, but in short you have three options:
Return no message and a VB friendly COM error, i.e. one well known by the VB runtime according to this KB article; the VB runtime will translate this 'COM error' to a VB error plus message.
Return an error message and DISP_E_EXCEPTION; the VB runtime will pass through this 'Server error' and your custom error message. This is what's implicitly happening on your second example, see below for details.
Return no message and any other COM error, i.e. one not known by the VB runtime; the VB runtime will resort to the raw HRESULT plus the generic message "Method '~' of object '~' failed".
Please note that this runtime behavior does also apply, if you do supply an error message here, i.e. your message will simply be ignored! This is what's happening on your first example, see below for details.
For the task at hand it boils down to two choices:
If you want to supply contextually correct 'COM errors' for automation clients like VB (and likely you should) you must omit custom error messages.
If you want to supply custom error messages for 'Server errors' (i.e. a custom error conditions regarding the functionality within your automation server) your only option is DISP_E_EXCEPTION.
Details
The VB runtime seems to offer only very restricted handling in regard to COM errors. This is likely for historic and/or technical reasons specific to the way VB has been implemented and not of particular interest here (keywords would be IDispatch only vs dual interface and ActiveX as a 'subset' of COM).
While I've been unable to surface an explicit specification for the behavior outlined above one can figure it from digging through other sources:
From the KB article justadreamer pointed out already:
[...] a call is made to the
GetErrorInfo method to retrieve the
available error information. The
runtime then determines whether
bstrDescription has a value other than
NULL. If the runtime finds a value
other than NULL, [...], the raw HRESULT
value is used in this scenario. If the
runtime finds a NULL value, [...]
Visual Basic then uses HRESULT
to look up the corresponding Visual
Basic error.
This explains the behavior regarding your fist example: you did supply an error message, hence the runtime simply resorts to its generic message "Method '~' of object '~' failed" plus your HRESULT.
The behavior of your second example is also consistent once you look at the definition of the (first listed) constructor for CComCoClass::Error: it has defaults for the non specified parameters, especially 'hRes = 0'. The 'Remarks' section further states that "If hRes is zero, then the first four versions of Error return DISP_E_EXCEPTION.". Consequently this implicitly triggers the 'Server error' pass through behavior.
Finally, for a concrete C++ implementation sample of a VB like automation client behavior see for example paragraphs 'Error handling' and the following 'Exercise 5' in Automating Microsoft Office 97 and Microsoft Office 2000.
Derive the class that implements your COM-exposed interface from ISupportErrorInfoImpl, call SetErrorInfo to set the detailed explanation of the error if any occurs. Don't forget to include ISupportErrorInfo into the COM_MAP of your class.
I'm struggling with this right now too. So far my digging indicates that the error code is really the HRESULT value. VB6 tries to be smart and interpret the HRESULT but it seems to have a fairly limited list of HRESULTs it understands. For the HRESULTs VB6 is not familiar with, it just puts the HRESULT into the Err.Number property and hopes that the developer is smart enough to figure out what to do with it.
The closest I've come to returning an error number is by using MAKE_SCODE to generate an HRESULT with the code field of the HRESULT set to what I want, the severity flag set and what I hope is the right facility.
That in conjunction with CreateErrorInfo and SetErrorInfo get me an error code and an error description in VB6. And that brings us back to VB6 trying to be smart with a limited list of errors.
Checkout this article http://support.microsoft.com/kb/827994. So your object must implement method ISupportsErrorInfo::InterfaceSupportsErrorInfo() which returns S_OK. and then before returning you must call SetErrorInfo with a pointer to a COM object which implements IErrorInfo::GetDescription().
There is an example here:
http://msdn.microsoft.com/en-us/library/ms221409.aspx.
If you SetErrorInfo before return, VB will query the GetDescription method of the object pointer you passed to SetErrorInfo.
I am not too deep in the attributed code you are using - I would prefer to test it using more raw COM which is surely always a lot of boilerplate code - but at least it works, then you could use sophisticated wrappers instead of it.