Re: Problem with get() method! - C# Discussion Boards

20-Jun-14 7:07

Hello everyone

I'm trying to solve this problem but i can't get it. Maybe someone can help me solve this problem please...

When I compile the error says:

Quote:
Error 'System.Collections.Generic.Dictionary<string,nhibernate.isessionfactory>' does not contain a definition for 'get' and no extension method 'get' accepting a first argument of type 'System.Collections.Generic.Dictionary<string,nhibernate.isessionfactory>' could be found (are you missing a using directive or an assembly reference?)

protected static ISessionFactory getSessionFactory(string configFile) 
        {
		    if (null == configFile) 
            {
			    if (sessionFactory == null) 
                {
                    throw new Exception("The session factory has not been initialized (or an error occurred during initialization)");
                }
			    else
                {
                    return sessionFactory;
                }
		    }
		    else 
            {
			    if (sessionFactoryMap == null)
                {
                    throw new Exception("The session factory for '" + configFile + "' has not been initialized (or an error occurred during initialization)");
                }
			    else 
                {
				    ISessionFactory sf = (ISessionFactory) sessionFactoryMap.get(configFile);
				    if (null == sf) 
                    {
                        throw new Exception("The session factory for '" + configFile + "' has not been initialized (or an error occured during initialization)");
                    }
				    else
                    {
                        return sf;
                    }
			    }
		    }
	    }

Thanks in advance

Eddy Vluggen20-Jun-14 7:59

20-Jun-14 7:59

It means there's no method name "get" on the ISessionFactory. Is the code from Java?

Try (ISessionFactory)sessionFactoryMap[configFile];

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

LAPEC20-Jun-14 8:14

20-Jun-14 8:14

Thanks for your help a lot, and actually it is from java code

Eddy Vluggen20-Jun-14 8:36

20-Jun-14 8:36

You're welcome Java | [Coffee]

LAPEC20-Jun-14 8:43

20-Jun-14 8:43

Can I please ask you for another help if you don't mind

LAPEC20-Jun-14 8:46

20-Jun-14 8:46

In this part of code im having error on get() and set() method...

<blockquote class="FQ"><div class="FQA">Quote:</div>protected static ISession getSession(string configFile, bool createNew) 
        {
		    if (createNew) 
            {
			    return getSessionFactory(configFile).OpenSession();
		    }
		    else 
            {
			    if (null == configFile) 
                {
				    if (null == sessions)
                    {
                        sessions = new ThreadLocal<ISession>();
                    }
				    ISession session = sessions.get();
				    if (null == session || !session.IsOpen) 
                    {
					    session = getSessionFactory(null).OpenSession();
					    session.set(session);
				    }
				    return session;
			    }
			    else 
                {
				    if (null == mappedSessions) 
                    {
                        mappedSessions = new ThreadLocal<IDictionary>();
                    }
                    Dictionary<string, ISession> map = mappedSessions.get();
				    if (null == map) 
                    {
                        map = new Dictionary<string, ISession>(1);
                        mappedSessions.set(map);
				    }
				    ISession session = map[configFile];
				    if (null == session || !session.IsOpen) 
                    {
					    session = getSessionFactory(configFile).OpenSession();
					    map.Add(configFile, session);
				    }
				    return session;
			    }
		    }
	    }</blockquote>

Eddy Vluggen20-Jun-14 9:01

20-Jun-14 9:01

According to MSDN, the ThreadLocal[^] class has a "Value" property that looks promising. ISessions session = sessions.Value?

Properties in C# do not need to explicitly call a getter/setter.

What kind of session is being created? Google is betting on NHibernate Smile | :)

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

LAPEC20-Jun-14 9:05

20-Jun-14 9:05

It is NHibernate

Eddy Vluggen20-Jun-14 9:23

Exception Handling / Response Question

20-Jun-14 9:23

Google for some C# example with NHibernate doing stuff with ISession and OpenSession; there's not much examples, but any that works would do Smile | :)

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Kevin Marois20-Jun-14 6:45

20-Jun-14 6:45

I posted on this a few months ago, and I need to revisit it...

I have a typical n-tier app - DAL, BL, WebAPI, Controllers, UI, etc.

I've seen many discussions on how to let the UI know that an exception happened in the back end. All have both good & bad points.

If you put a TRY/CATCH in the DAL, log the error, then what..??? Throw again and catch it again in a UI side TRY/CATCH?

What about situations where it's NOT an exception, but the UI needs to know something, like a duplicate record problem, or a record in use and can't be deleted problem? Would you throw for these also?

What I WAS doing was passing back a custom response object from each DAL method. My Response class:

[DataContract]
[Serializable]
public class _ResponseBase
{
    [DataMember]
    public Result Result { get; set; }

    [DataMember]
    public string Message { get; set; }

    private Exception _Exception;
    [DataMember]
    public Exception Exception 
    {
        get { return _Exception; }
        set 
        {
            if (_Exception != value)
            {
                _Exception = value;
                Result = Result.Failure;
                Message = _Exception.Message;
            }
        } 
    }

    public _ResponseBase()
    {
        Result = Result.Success;
        Message = string.Empty;
        Exception = null;
    }
}

This class allows you to pass back Result.Success with the data from the DAL, or Result.Failure with a message such "Duplicate record", or Result.Failure with an Exception.

Then in the UI's base View Model I have a method called HandleResponse that is called like:

var response = Engine.APIProxy.GetLookups(AppConstants.TRAINING_CATEGORIES);

if (response.Result == Result.Success)
{
    Categories = new ObservableCollection<LookupEntity>(response.Data);
}
else
{
    HandleResponse(response);
}

and the HandleResponse method:

protected void HandleResponse(_ResponseBase response)
{
    if (response.Exception == null)
    {
        if (!string.IsNullOrEmpty(response.Message))
        {
            MessageBox.Show(response.Message, "Response", MessageBoxButton.OK, MessageBoxImage.Information);
        }
        else
        {
            throw new ArgumentException("The response did not contain an exception or a message");
        }
    }
    else
    {
        logException(response.Exception);
        throw response.Exception;
    }
}

There is a WPF UI, a WPF Tablet App, and a Web App that all go through the Web API, so having a consistent response object returned is very helpful, although it does mean a bit more UI code.

So far this works well, but I'd like to get your opinion. Do you have a better way?

Thanks

If it's not broken, fix it until it is

PIEBALDconsult20-Jun-14 7:37

PIEBALDconsult

20-Jun-14 7:37

I prefer the general "don't catch it if you're not going to do anything with it" theory. Let it bubble up unmolested until something can actually handle it.

Just above that, is the "catch it, add relevent information to the Data collection, and rethrow it" theory.
As regards database operations, I like to add the SQL statement, parameters, and maybe connection information.
You can also add a timestamp and other information -- too much is better than too little.
Such information should not be presented to the user of course.

In some cases, it makes sense to catch the exception and wrap it in a more descriptive (perhaps custom) exception.
As you probably know, a database problem will just produce a general exception -- which is fairly useless.
When appropriate, you can determine more detail about the exception and throw a more appropriate derived exception -- e.g. DuplicateDataException -- which can help the eventual handler.
I'm of the opinion that such spelunking should be done at the lowest level so the higher levels don't need to know the details of the particular connection in use.
Retain the caught exception as the InnerException, in case the handler does want to know.

Similarly, if logging of the exception is to be performed, it should be done at the highest level that makes sense, not the lowest level. Logging is an application responsibility, not a framework responsibility.

Finally, when catching-and-rethrowing, use throw, not throw ex .

You'll never get very far if all you do is follow instructions.

Kevin Marois20-Jun-14 7:39

20-Jun-14 7:39

I agree with everything you wrote.

But you didn't answer my design question. Anything wrong with the concept of returning responses?

If it's not broken, fix it until it is

PIEBALDconsult20-Jun-14 7:44

PIEBALDconsult

20-Jun-14 7:44

Kevin Marois wrote:
Anything wrong with the concept of returning responses?

Other than it being some of that Web Stuff? I don't speak that language.

You'll never get very far if all you do is follow instructions.

Kevin Marois20-Jun-14 7:52

20-Jun-14 7:52

It's a WPF app. There's a web app that also uses the API

If it's not broken, fix it until it is

PIEBALDconsult20-Jun-14 8:05

PIEBALDconsult

20-Jun-14 8:05

Kevin Marois wrote:
a WPF app

Whatever that is. Roll eyes | :rolleyes:

I try to stay in the backend, plus console apps as needed, and WinForms when appropriate.

You'll never get very far if all you do is follow instructions.

Eddy Vluggen20-Jun-14 8:05

20-Jun-14 8:05

Kevin Marois wrote:
If you put a TRY/CATCH in the DAL, log the error, then what..??? Throw again and
catch it again in a UI side TRY/CATCH?

No, don't ever add code that does nothing or adds nothing.

Kevin Marois wrote:
What about situations where it's NOT an exception, but the UI needs to know
something, like a duplicate record problem

A duplicate record simply is an exception.

Kevin Marois wrote:
So far this works well, but I'd like to get your opinion. Do you have a better
way?

No, I don't.

I prefer exceptions over return-values, as they force the programmer to anticipate in handling them, whereas returnvalues can and will be ignored. Then some wiseguy came up with the idea to ignore exceptions as well.

Oh, well.

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Kevin Marois20-Jun-14 8:18

20-Jun-14 8:18

The problems I'm trying to address are

1) Try/Catch blocks All Over.

You always want try/catch's wrapping your DAL data methods. If you rely on catching exceptions in the UI, then other apps that use the DAL might not handle then properly and you open the door to corrupted data or unhandled exceptions.

When I see a method header like

void SomeFunction();

I don't know what's happening in the method, weather it's handling exceptions or not. But if I see this:

Response<SomeEntity> SomeFunction();

and I look at the Response and see an Exception property, then I can reasonably know that the method is handling exceptions in the DAL. I would still need to check the exception, but it might NOT be an exception. It could simply be some message suck as "Customer credit limit exceeded".

2) Provide a means to communicate other issues to the caller.

I do not agree that a duplicate record is an exception. First, it really is an issue of the business rules. Second, the user types in "Blah" and saves, and then "Blah" again and saves, and the app should log & throw?? Really? The app should notify the user, but no other action is necessary.

3). Provide a single point of handling problems, and a single method for returning info to the caller. There will most certainly be other applications accessing this data via the API. Since I don't know right now what they are, setting up the DAL to return responses instead of just throwing seems logical because I'm not relying on some other app or person to handle it. The DAL handles it and the programmer can do whatever they want with the response.

Just my 2 cents.

If it's not broken, fix it until it is

Eddy Vluggen20-Jun-14 9:21

20-Jun-14 9:21

Kevin Marois wrote:
1) Try/Catch blocks All Over.

Yup, those are a problem. If you don't intend to do something with it (logging should be done at the least amount of levels required) then don't write a handler. Let it bubble up. Don't add yet another empty handler.

Kevin Marois wrote:
You always want try/catch's wrapping your DAL data methods

Even if it is a Win32Exception whose error-message I can get, it is usually something the end-user can handle, not I. The options are often "try again" or "fail".

But then again, I don't do generic exception handling in a DAL-layer. If there's a disk-full message, then it bubbles up, is displayed, and can only be dismissed. The action can be tried again (by the user) after that oc. If it cannot be retried automatically, then there's no local handler, and the threads' exception handler will take care of it. There's sldo no need to catch-and-rethrow some validation exception, that's the responsibility of the calling code.

Kevin Marois wrote:
I do not agree that a duplicate record is an exception. First, it really is an
issue of the business rules.

You do not have to; it's not the BR-rules that define how the data is saved most efficiently. There technically cannot be "duplicate" records in a relational database. If your BR require for "duplicates", I'll add an identity-field (an artificial key in normalization terms) to distinguish between both entities. The identity would be the PK, and there'd be a unique key on the things you use to distinguish between records to identify (and if need be, notify) of breach of such a BR-constraint.

Kevin Marois wrote:
Second, the user types in "Blah" and saves, and then "Blah" again and saves, and
the app should log & throw?? Really? The app should notify the user, but no
other action is necessary.

It depends on the case. If it is a unique constraint, and a new baby gets an existing social security number, then you might want to throw an exception stating merely "computer says no". I do not know al the reasons why there cannot exist two identities with the same unique identifying key; only the user knows - and sometimes the dev has to remind the user he/she doesn't know either.

[Serializable]
public class ComputerSaysNoException : Exception
{
  public ComputerSaysNoException() { }
  public ComputerSaysNoException( string message ) : base( message ) { }
  public ComputerSaysNoException( string message, Exception inner ) : base( message, inner ) { }
  protected ComputerSaysNoException(
    System.Runtime.Serialization.SerializationInfo info,
    System.Runtime.Serialization.StreamingContext context ) : base( info, context ) { }
}

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Kevin Marois20-Jun-14 10:22

20-Jun-14 10:22

Eddy Vluggen wrote:
You do not have to; it's not the BR-rules that define how the data is saved most efficiently. There technically cannot be "duplicate" records in a relational database

Agreed.. the BL doesn't have anything to do with HOW the data is saved. It's concerned with WHAT data is saved.

You're confusing a Business Rule Violation with an Exception. What is an exception? It's simply a fancy word for Error. A BR violation isn't an error. It's a condition that can't be allowed to continue on to the DAL.

An example would be a customer's credit limit being reached. The DAL never gets called because the BL determined that a business rule would be violated if it continued.

And to say "There technically cannot be "duplicate" records in a relational database" isn't always true. Again, this is something determined by the app requirements.

My point in all this is that I think I've come up with a standardized way of returning to the call ANYTHING that happens, whether it's a BL violation or an exception.

If it's not broken, fix it until it is

Eddy Vluggen20-Jun-14 11:05